È una chiave privata SSH protetta da passphrase suscettibile a un attacco di dizionario?

Non è la lunghezza della passphrase che conta, ma la sua casualità; vale a dire, quanto avrebbe potuto essere diverso. La lunghezza fa spazio alla casualità, ma non la genera.

La crittografia simmetrica delle chiavi private SSH non è molto ben progettata; si basa su alcune vecchie funzionalità di OpenSSL, che risalgono a prima di hashing password era un problema ben compreso. Vedi questa risposta per un'analisi dettagliata. In conclusione, gli attaccanti saranno in grado di provare le potenziali password di un miliardo al secondo, a meno che non si investa un po 'di impegno per avvolgere la chiave in un oggetto PKCS # 8 con PBKDF2 e cicli sufficienti.

Se si genera la passphrase come una sequenza di lettere, ciascuna scelta casualmente e in modo uniforme, si otterranno 4,7 bit di entropia per lettera (poiché 26 è approssimativamente uguale a 2 ^4.7 ). Per raggiungere un livello di protezione decente (ad esempio, 100 bit), avrai bisogno di 22 lettere ... Se preferisci generare parole significative , diciamo tra un elenco di 2048" parole comuni ", quindi otterrete 11 bit per parola e 9 parole vi porteranno a 99 bit di entropia. Anche in questo caso, ogni parola deve essere scelta a caso, in modo uniforme e indipendentemente dalle altre parole.

Con PKCS # 8 + PBKDF2 e un milione di round (OpenSSL avrebbe bisogno di un po 'di coassialità per produrlo), guadagni 20 bit (perché 2 ²⁰ è approssimativamente uguale a un milione).

Ricorda che ricordare , in effetti, può essere difficile. Ricorderai una passphrase molto lunga, ma solo se la digiti abbastanza spesso. Se non lo fai, allora l'oblio è quasi garantito. Ti suggerisco di stampare la tua passphrase molto lunga e di conservarla in una banca (stampare con una stampante laser, non con una stampante a getto d'inchiostro: l'inchiostro di quest'ultimo può svanire piuttosto rapidamente). Oppure, più semplice, taglia il middle man e stampa la chiave stessa sulla carta che hai messo in cassastrong.

^{(*) Nota: i sistemi di stampa possono conservare una copia cache dei lavori di stampa passati. Rimuovere tutte le tracce può essere complicato. Potresti utilizzare un processo di "stampa manuale" con una penna e la tua mano ... per una conservazione davvero a lungo termine, considera l'incisione su pietra o su un metallo resistente alla ruggine.}

Questo è un argomento molto interessante. Uno a cui è stata data una risposta prima su Stack Exchange. Bruce Schneier è un esperto riconosciuto e esperto in crittografia. Qui puoi trovare un articolo sul tema degli attacchi di forza bruta:

Perché non utilizzare chiavi cifrate più grandi?

I passaggi più interessanti sono riprodotti qui:

Longer key lengths are better, but only up to a point. AES will have 128-bit, 192-bit, and 256-bit key lengths. This is far longer than needed for the foreseeable future. In fact, we cannot even imagine a world where 256-bit brute force searches are possible. It requires some fundamental breakthroughs in physics and our understanding of the universe.

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k = 1.38 × 10⁻¹⁶ erg/K, and that the ambient temperature of the universe is 3.2 Kelvin, an ideal computer running at 3.2 K would consume 4.4 × 10⁻¹⁶ ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.

Now, the annual energy output of our sun is about 1.21 × 10⁴¹ ergs. This is enough to power about 2.7 × 10⁵⁶ single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2¹⁹². Of course, it wouldn't have the energy left over to perform any useful calculations with this counter.

But that's just one star, and a measly one at that. A typical supernova releases something like 10⁵¹ ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

Spero che lo trovi interessante.

If this SSH private key is really not practically decryptable, then I intend to protect it with a VERY long passphrase and then forget all about securing the key itself.

Le chiavi private crittografate sono suscettibili agli attacchi a forza bruta se l'attaccante può mettere le mani sulla tua chiave privata crittografata. E se non può, allora non lo sono. La crittografia non è magica; in genere è un triplo DES molto comune, ed è sempre un attacco offline, quindi l'attaccante è libero di utilizzare l'hardware dedicato.

Inserire la chiave crittografata nella casella Gmail o Google Drive o Dropbox è probabilmente abbastanza sicuro. L'elenco delle persone interessate alla tua chiave non si sovrappone molto alla lista delle persone che hanno accesso al tuo account Gmail.

Ma visualizzarlo pubblicamente sulla tua pagina web è un po 'esagerato. Stai letteralmente chiedendo a qualcuno di provare a decifrarlo. Per lo meno mettere in atto misure per impedire l'accesso a osservatori casuali.

Una password alfanumerica di 20 caratteri è di circa 120 bit, che non può essere facilmente forzata dalla tecnologia odierna. Ma anche così, un po 'di buon senso è probabilmente in ordine.

Questa è una vecchia domanda, ma nel caso in cui qualcuno incontri questa ricerca di risposte, le cose sono cambiate :

 -o      Causes ssh-keygen to save private keys using the new OpenSSH
         format rather than the more compatible PEM format.  The new
         format has increased resistance to brute-force password cracking
         but is not supported by versions of OpenSSH prior to 6.5. Ed25519
         keys always use the new private key format.

(dalla pagina man di ssh-keygen)

Apparentemente, questo utilizza bcrypt , che è considerato un bel lento , strong KDF. Mentre il suo utilizzo fisso della memoria lo rende più vulnerabile agli attacchi paralleli massivi che utilizzano GPU, FPGA o ASIC di qualcosa come scrypt (che può essere regolato per richiedere quantità di memoria abituali per il calcolo), è tutto il mondo a portata di singolo round di MD5 che usa il vecchio formato.

Inoltre, è possibile utilizzare l'opzione -a per specificare il fattore di lavoro utilizzato, che può essere utilizzato per aumentare ulteriormente la resistenza della forza bruta del file di chiavi. Vale la pena sperimentare questo per trovare il massimo valore tollerabile; Ho usato 200, che sul mio vecchio cellulare i7 di seconda generazione impiega circa 2 secondi per decodificare.

Per riferimento, qui è un punto di riferimento di ciò che può fare un impianto di cracking top-of-the-line nel 2017 : ~ 100k indovina / sec su 8 GPU top-end. Questo è con un fattore di lavoro bcrypt di 5, che è molto più basso di quello che usa OpenSSH (che credo sia 16 di default? (È una scala esponenziale, aumentando il fattore di lavoro di 1 raddoppia il tempo di hashing) La relazione tra -a Il valore e il fattore di lavoro effettivo di bcrypt non sono chiari.)