Scegli RSA.

DSA è più veloce per la generazione della firma ma più lento per la convalida, più lento durante la crittografia ma più veloce quando la decrittografia 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 numeri interi grandi è nota per essere "difficile", mentre la sicurezza DSA si basa sul problema del logaritmo discreto. Oggi l'algoritmo più veloce conosciuto per la fattorizzazione di numeri interi di grandi dimensioni è il General Number Field Sieve, anche l'algoritmo più veloce per risolvere il problema del logaritmo discreto in campi finiti modulo un grande primo p come specificato per DSA.

Ora, se la sicurezza può essere considerata uguale, ovviamente preferiremmo l'algoritmo più veloce. Ma ancora una volta, non c'è un vincitore chiaro.

Puoi dare un'occhiata a questo studio o, se hai OpenSSL installato sul tuo computer, eseguire openssl speed codice>. Vedrai che DSA funziona più velocemente nella generazione di una firma ma molto più lentamente quando verifica una firma della stessa lunghezza di chiave. La verifica è generalmente ciò che vuoi essere più veloce se gestisci ad es. con un documento firmato. La firma viene generata una volta, quindi va bene se questo richiede un po 'più di tempo, ma la firma del documento può essere verificata molto più spesso dagli utenti finali.

Entrambi supportano una qualche forma di metodo di crittografia, RSA fuori dal box e DSA utilizzando un El Gamal. DSA è generalmente più veloce nella decrittografia 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 decrittografato molte volte.

In termini commerciali, RSA è chiaramente il vincitore, i certificati RSA commerciali sono molto più ampiamente distribuiti 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 a FIPS 186-2 NIST a>. Quindi, sebbene in teoria siano possibili chiavi DSA più lunghe (FIPS 186-3 le consente esplicitamente), sei comunque limitato a 1024 bit. E se prendi le considerazioni di questo [articolo], non siamo più protetti con 1024 bit per RSA o DSA.

Quindi, oggi, stai meglio con un RSA 2048 o 4096 bit chiave.

In questo momento la domanda è un po 'più ampia: RSA contro DSA contro ECDSA contro Ed25519 . Quindi:

Una presentazione al BlackHat 2013 suggerisce che sono stati compiuti progressi significativi nella risoluzione dei problemi sulla complessità di cui la forza dei DSA e alcuni altri gli algoritmi sono fondati, quindi possono essere matematicamente rotti molto presto. Inoltre, l'attacco può essere possibile (ma più difficile) da estendere anche a RSA.

La presentazione suggerisce invece di utilizzare la crittografia a curva ellittica. Gli algoritmi ECC supportati da OpenSSH sono ECDSA e, a partire da OpenSSH 6.5, Ed25519.

OpenSSH supporta solo curve NIST per ECDSA e secondo questo studio quelle curve sembrano davvero sospette per le backdoor NSA. E se la NSA è già in grado di decifrarle, allora non sarà così difficile da decifrare per qualcun altro come sarebbe una curva corretta. Ed25519 è la stessa cosa ma con una curva migliore, quindi è la scommessa più sicura contro l'algoritmo sottostante che viene infranto matematicamente .

Inoltre, DSA ed 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 connetti al tuo server da una macchina con un generatore di numeri casuali scadente e ad es. lo stesso k viene utilizzato due volte, un osservatore del traffico può capire la tua chiave privata. (fonte: Wikipedia su DSA e ECDSA, anche questo).

La conclusione è:

• Non utilizzare mai DSA o ECDSA .
• Ed25519 è probabilmente il più potente matematicamente (e anche il più veloce), ma non ancora ampiamente supportato. Come bonus, ha una crittografia più forte (protezione tramite password) della chiave privata per impostazione predefinita rispetto ad altri tipi di chiave.
• RSA è la soluzione migliore se non puoi utilizzare Ed25519 .

In SSH, sul lato client, la scelta tra RSA e DSA non ha molta importanza, perché entrambi offrono una sicurezza simile per la stessa dimensione 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 che potesse essere realizzata un'implementazione opensource priva di brevetto. Il brevetto RSA è scaduto più di 10 anni fa, quindi non ci sono più preoccupazioni.

Teoricamente, in alcune situazioni molto specifiche, puoi avere un problema di prestazioni con l'una o l'altra: se il server è molto piccolo macchina (ad esempio, un i486), preferirà client con chiavi RSA, perché la verifica di una firma RSA è meno costosa dal punto di vista computazionale rispetto alla verifica di una firma DSA. Al contrario, una firma DSA è più corta (in genere 64 byte contro 256), quindi se sei molto a corto di larghezza di banda preferiresti DSA. Ad ogni modo, avrai difficoltà a rilevare quegli effetti, per non parlare di trovarli importanti.

Sul server , è preferibile una chiave DSA, perché quindi lo scambio di chiavi utilizzerà una chiave Diffie-Hellman transitoria, che apre la strada a "Perfect Forward Secrecy" (cioè se un malintenzionato ruba la chiave privata del server, non può ancora decrittare le connessioni passate che avrebbe registrato).

Un altro importante vantaggio di RSA rispetto a DSA ed ECDSA è che non è mai necessario un generatore di numeri casuali sicuro per creare firme.

Per generare una firma, (EC) DSA ha bisogno di un valore che deve essere casuale, segreto / imprevedibile e non può essere mai più utilizzato. Se una di queste proprietà viene violata, è possibile recuperare banalmente la chiave privata da una o due firme .

Questo è già successo (una volta con una patch non funzionante 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 solo la tua chiave di sessione temporanea sarebbe stata compromessa, se la chiave di autenticazione effettiva le coppie sono state create utilizzando un PRNG correttamente inizializzato in precedenza.

Teoricamente, esiste un modo per far dipendere le firme DSA (EC) dal messaggio e dalla chiave privata, il che può evitare fallimento in caso di un RNG rotto, ma fino a quando questo non viene integrato nel tuo client SSH (non esiste una versione di rilascio di OpenSSL che includa la patch in questo momento), preferirei sicuramente le chiavi RSA.

Non sapendo molto di crittografia, come utente di OpenSSH mi atterrei a un semplice fatto: in http://www.openssh.com/legacy.html, che afferma che SHA1 è ora disabilitato per impostazione predefinita perché è considerato debole:

OpenSSH 7.0 e versioni successive disabilitano in modo simile l'algoritmo della chiave pubblica ssh-dss (DSA) . Anch'esso è debole e ne sconsigliamo l'uso.

La matematica potrebbe non avere importanza. Questo thread sembra pre-Snowden. Ecco un articolo Reuters datato 20 dicembre 2013:

(Reuters) - Come parte fondamentale di una campagna per incorporare software di crittografia che potrebbe essere utilizzato ampiamente Reuters ha appreso che la US National Security Agency ha stipulato un contratto segreto da 10 milioni di dollari con RSA, una delle aziende più influenti nel settore della sicurezza informatica.

Documenti trapelati dall'ex appaltatore della NSA Edward Snowden mostrano che La NSA ha creato e promulgato una formula viziata per la generazione di numeri casuali per creare una "porta di servizio" nei prodotti di crittografia, ha riferito il New York Times a settembre. Reuters ha successivamente riferito che RSA è diventato il distributore più importante di quella formula inserendola in uno strumento software chiamato Bsafe che viene utilizzato per migliorare la sicurezza nei personal computer e in molti altri prodotti.

Finora non è stato divulgato che RSA ha ricevuto $ 10 milioni in un accordo che ha impostato la formula NSA come metodo preferito o predefinito per la generazione di numeri nel software BSafe, secondo due fonti che hanno familiarità con il contratto. Sebbene questa somma possa sembrare irrisoria, rappresentava più di un terzo delle entrate che la divisione pertinente di RSA aveva incassato durante l'intero anno precedente, come mostrano le dichiarazioni di titoli.

Durante questo venerdì della scienza podcast Ira chiede a Matt Green, Martin Hellman (inventore di Public Key Cryptography) e Phil Zimmerman (creatore di PGP) cosa pensano che la NSA abbia decifrato:

(intorno alle 17: 26)

Ira : Quali sono alcune delle cose in cui sappiamo che la NSA ha violato?

Matt : Quindi abbiamo sentito una serie di cose che probabilmente possiamo accreditare per davvero. ... generatori di numeri casuali ... sappiamo che la NSA attraverso il NIST ... ha molto probabilmente messo delle porte secondarie in alcuni di quegli algoritmi standard che consentono loro di rompere essenzialmente quei sistemi completamente.

Ira : Vuoi dire che la NSA ha creato quelle porte sul retro?

Matt : È esattamente vero. Quindi il NIST lavora con la NSA --- e sono tenuti a farlo per legge. Pensavamo che la NSA stesse aiutando il NIST sviluppando standard più sicuri da utilizzare per gli americani. Ora sospettiamo - e abbiamo forti prove per credere - che la situazione fosse esattamente l'opposto; che il NIST veniva utilizzato per pubblicare standard che la NSA poteva infrangere.

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 DSA è stata creata dallo stesso NIST, che, secondo questi esperti, è in gran parte una copertura per la ricerca crittografica della NSA.

In altre parole, è davvero non importa se stai usando i generatori di numeri casuali forniti con praticamente qualsiasi computer moderno, cosa che fanno OpenSSH e altri.

Scegli quello che è il più veloce per quello che vuoi. Nel mio caso, riutilizzo la stessa chiave per molte cose, quindi la maggiore velocità di generazione di DSA è meno desiderabile. Inoltre, forse c'è qualche folle possibilità che RSA fosse in realtà un'entità indipendente da NIST e NSA, mentre sappiamo che DSA è stato creato da NIST.

Personalmente uso solo chiavi a 1028 bit perché, come abbiamo visto , non importa a meno che qualcuno non ti stia ponendo dei requisiti che crede ancora che chiavi più grandi ti proteggeranno. L'intera cosa è in gran parte solo un fastidio per chiunque cerchi di entrare.

RSA e DSA sono due algoritmi completamente diversi. Le chiavi RSA possono arrivare fino a 4096 bit, dove DSA deve essere esattamente 1024 bit (sebbene OpenSSL ne consenta di più). Secondo Bruce Schneier, "sia DSA che RSA con la stessa lunghezza sono quasi identici in termini di difficoltà da decifrare."

Il problema con ECDSA non sono tanto le backdoor. Bernstein / Lange menzionano specificamente che la crittoanalisi delle curve non attacca curve specifiche, ma classi di curve (vedi diapositiva 6).

Il problema con ECDSA è che le curve NIST sono difficili da implementare correttamente (es. tempo costante e con tutte le verifiche appropriate) rispetto a Curve25519. OpenSSL ha un ' implementazione P256 a tempo costante, quindi OpenSSH è sicuro sotto questo aspetto.

Se sei ancora preoccupato per le curve NIST, OpenSSH ha recentemente aggiunto il supporto per lo schema Ed25519