Quando generi chiavi di autenticazione SSH su un sistema Unix / Linux con ssh-keygen , ti viene data la possibilità di creare una coppia di chiavi RSA o DSA (utilizzando -t type ).
Qual è la differenza tra le chiavi RSA e DSA? Cosa porterebbe qualcuno a sceglierne uno rispetto all'altro?
Vai con RSA.
DSA è più veloce per la generazione di firme, ma più lento per la convalida, più lento durante la crittografia, ma più veloce durante la decodifica e la sicurezza può essere considerata equivalente rispetto a una chiave RSA di uguale lunghezza della chiave. Questa è la battuta finale, ora qualche giustificazione.
La sicurezza dell'algoritmo RSA si basa sul fatto che la fattorizzazione di grandi numeri interi è nota per essere "difficile" , mentre la sicurezza DSA si basa sul problema discreto logaritmo . Oggi l'algoritmo più noto per il factoring di numeri interi grandi è il Numero generale di campo Sieve , anche l'algoritmo più veloce per risolvere il problema del logaritmo discreto nei campi finiti modulo un grande primo p come specificato per DSA.
Ora, se la sicurezza può essere considerata uguale, vorremmo naturalmente favorire l'algoritmo più veloce. Ma ancora, non c'è un vincitore chiaro.
Potresti dare un'occhiata a questo studio o, se hai OpenSSL installato sul tuo macchina, esegui openssl speed . Vedrai che DSA si comporta più rapidamente nella generazione di una firma, ma molto più lentamente quando verifica una firma della stessa lunghezza della chiave. La verifica è generalmente ciò che desideri essere più veloce se ti occupi ad es. con un documento firmato La firma viene generata una volta, quindi va bene se questo richiede più tempo, ma la firma del documento può essere verificata molto più spesso dagli utenti finali.
Entrambi supportano alcune forme di metodo di crittografia, RSA immediato e DSA utilizzando un El Gamal . DSA è generalmente più veloce in decrittazione, ma più lento per la crittografia, con RSA è il contrario. Ancora una volta vuoi che la decrittografia sia più veloce qui perché un documento crittografato potrebbe essere decodificato molte volte.
In termini commerciali, RSA è chiaramente il vincitore, i certificati RSA commerciali sono distribuiti molto più ampiamente rispetto ai certificati DSA.
Ma ho salvato l'argomento killer per la fine: man ssh-keygen dice che una chiave DSA deve essere lunga esattamente 1024 bit per essere conforme al FIPS 186-2 . Quindi, anche se in teoria sono possibili chiavi DSA più lunghe (anche FIPS 186-3 consente loro esplicitamente) si è ancora limitati a 1024 bit. E se prendi le considerazioni su questo [articolo], non siamo più sicuri con 1024 bit per RSA o DSA.
Così oggi ti trovi meglio con una chiave RSA a 2048 bit.
In questo momento la domanda è un po 'più ampia: RSA contro DSA contro ECDSA contro Ed25519 . Quindi:
Una presentazione a BlackHat 2013 suggerisce che sono stati compiuti progressi significativi nella soluzione dei problemi di complessità di cui la forza di DSA e di altri algoritmi è stata fondata, quindi possono essere matematicamente non tagliati molto presto. Inoltre, l'attacco potrebbe essere possibile (ma più difficile) estendere anche a RSA.
La presentazione suggerisce invece di utilizzare la crittografia a curva ellittica. Gli algoritmi ECC supportati da OpenSSH sono ECDSA e, dal momento che OpenSSH 6.5, Ed25519.
OpenSSH supporta solo le curve NIST per ECDSA e secondo questo studio quelle curve sembrano davvero sospette per < strong> backdoor NSA. E se la NSA può già decifrarla, allora non sarà difficile da decifrare per qualcun altro come sarebbe una curva adeguata. Ed25519 è la stessa cosa ma con una curva migliore, quindi è la scommessa più sicura contro l'algoritmo sottostante che è matematicamente rotto.
Inoltre, DSA e ECDSA hanno una proprietà sgradevole: richiedono che un parametro solitamente chiamato k sia completamente casuale, segreto e unico. In pratica ciò significa che se ti colleghi al tuo server da una macchina con un generatore di numeri casuali scarso e ad es. lo stesso k è usato per due volte, un osservatore del traffico può capire la tua chiave privata. (fonte: Wikipedia su DSA e ECDSA , anche questo )
.La linea di fondo è:
In SSH, sul lato client, la scelta tra RSA e DSA non ha molta importanza, perché entrambi offrono una sicurezza simile per le stesse dimensioni della chiave (usa 2048 bit e sarai felice).
Storicamente, la versione 1 del protocollo SSH supportava solo le chiavi RSA. Quando è stata definita la versione 2, RSA era ancora brevettata, quindi è stato aggiunto il supporto di DSA, in modo da poter realizzare un'implementazione open source priva di brevetti. Il brevetto RSA è scaduto più di 10 anni fa, quindi non c'è più nessuna preoccupazione ora.
Teoricamente, in alcune situazioni molto specifiche, puoi avere un problema di prestazioni con uno o l'altro: se il server è una macchina molto piccola (ad esempio un i486), preferirà i client con chiavi RSA, perché verifica un RSA la firma è meno dispendiosa dal punto di vista computazionale rispetto alla verifica di una firma DSA. Viceversa, una firma DSA è più breve (in genere 64 byte vs 256), quindi se la larghezza di banda è molto bassa, preferirai il DSA. Ad ogni modo, avrai difficoltà a scoprire quegli effetti, per non parlare di trovarli importanti.
Sul server , è preferibile una chiave DSA, perché in quel caso lo scambio di chiavi utilizzerà una chiave transitoria Diffie-Hellman, che apre la strada a "Perfect Forward Secrecy" (cioè se un cattivo ragazzo ruba la chiave privata del server, non può ancora decifrare le connessioni precedenti che avrebbe registrato).
Un altro importante vantaggio di RSA rispetto a DSA e ECDSA è che non è mai necessario un generatore di numeri casuali sicuro per creare firme.
Per generare una firma, il DSA (EC) ha bisogno di un valore che deve essere casuale, segreto / imprevedibile e mai più utilizzabile . Se una di queste proprietà viene violata, è possibile recuperare in modo triviale la chiave privata da una o due firme .
Questo è successo prima (una volta con una patch rotta di OpenSSL PRNG in Debian e una volta con un bug nell'implementazione SecureRandom di Android) ed è piuttosto difficile da prevenire completamente.
Con RSA, in quelle situazioni sarebbe stata compromessa solo la tua chiave di sessione temporanea, se le coppie di chiavi di autenticazione effettive sono state create utilizzando un PRNG correttamente seminato in precedenza.
In teoria, c'è un modo per rendere le firme DSA (EC) dipendono dal messaggio e dalla chiave privata, che può evitare il fallimento totale in caso di un RNG rotto, ma fino a quando non viene integrato nel client SSH (non esiste una versione di rilascio OpenSSL che includa la patch in questo momento), mi piacerebbe sicuramente andare con le chiavi RSA.
Non conoscendo molto della crittografia, come utente OpenSSH vorrei attenermi a un semplice fatto: in link , che afferma SHA1 è ora disabilitato di default perché è considerato debole:
OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.
RSA e DSA sono due algoritmi completamente diversi. Le chiavi RSA possono arrivare a 4096 bit, in cui DSA deve essere esattamente 1024 bit (sebbene OpenSSL ne consenta di più). Secondo Bruce Schneier, "sia DSA che RSA con gli stessi tasti di lunghezza sono praticamente identici nella difficoltà di crack".
Il problema con ECDSA non è tanto backdoor. Bernstein / Lange menzionano specificamente che la cryptanalisi della curva non attacca curve specifiche, ma classi di curve (vedi slide 6 ).
Il problema con ECDSA è che le curve NIST sono difficili da implementare correttamente (cioè tempo costante e con tutte le verifiche corrette) rispetto a Curve25519. OpenSSL ha una implementazione P256 a tempo costante , quindi OpenSSH è sicuro questo riguardo.
Se sei ancora preoccupato per le curve NIST, OpenSSH ha recentemente aggiunto il supporto per lo schema Ed25519
La matematica potrebbe non avere importanza. Questa discussione sembra pre-Snowden. Ecco un articolo di Reuters del 20 dicembre 2013 :
(Reuters) - As a key part of a campaign to embed encryption software that it could crack into widely used computer products, the U.S. National Security Agency arranged a secret $10 million contract with RSA, one of the most influential firms in the computer security industry, Reuters has learned.
Documents leaked by former NSA contractor Edward Snowden show that the NSA created and promulgated a flawed formula for generating random numbers to create a "back door" in encryption products, the New York Times reported in September. Reuters later reported that RSA became the most important distributor of that formula by rolling it into a software tool called Bsafe that is used to enhance security in personal computers and many other products.
Undisclosed until now was that RSA received $10 million in a deal that set the NSA formula as the preferred, or default, method for number generation in the BSafe software, according to two sources familiar with the contract. Although that sum might seem paltry, it represented more than a third of the revenue that the relevant division at RSA had taken in during the entire previous year, securities filings show.
Durante questo podcast di Science Friday Ira chiede Matt Green , Martin Hellman (inventore di Public Key Cryptography), e Phil Zimmerman (creatore di PGP), cosa pensano che la NSA abbia incrinato:
(intorno alle 17:26)
Ira: What are some of the things that we know that the NSA has broken into?
Matt: So we have heard a number of things that we can probably credit for real. … random number generators … we know that NSA through NIST … has very likely put back doors in some of those standard algorithms that allow them to essentially break those systems entirely.
Ira: You mean the NSA created those back doors?
Matt: That's exactly right. So NIST works with NSA --- and they're required to by law. We thought NSA was helping NIST by developing more secure standards for Americans to use. We now suspect --- and have strong evidence to believe --- that the situation was exactly the opposite; that NIST was being used to put out standards that the NSA could break.
Considerando queste recenti rivelazioni, la forza degli algoritmi sembra in gran parte irrilevante. RSA sembra essere stata una società privata in qualche modo acquistata dalla NSA, e la DSA è stata creata dal NIST stesso, che, secondo questi esperti, è in gran parte un fronte per la ricerca sulla cripta della NSA.
In altre parole, non importa se si utilizzano generatori di numeri casuali forniti praticamente da qualsiasi computer moderno, quali OpenSSH e altri.
Scegli quello che è il più veloce per quello che vuoi. Nel mio caso, riuso la stessa chiave per un sacco di cose, quindi la velocità di generazione più veloce di DSA è meno desiderabile. Inoltre, forse c'è qualche possibilità che RSA fosse in realtà un'entità indipendente da NIST e NSA, mentre sappiamo che il DSA è stato creato dal NIST.
Personalmente uso solo le chiavi da 1028 bit perché, come abbiamo visto, non importa se qualcuno non sta ponendo dei requisiti su chi crede ancora che le chiavi più grandi ti proteggeranno. Il tutto è in gran parte solo un fastidio per tutti coloro che cercano di entrare.
Leggi altre domande sui tag authentication cryptography encryption ssh key-management