Panoramica

1. Alcuni esempi di revisione / discussione.
2. Alternativa: chiave generata da password locale per uso interno nell'API di controllo della chiave di crittografia.
3. Entropy e aumentandolo.

1. Alcuni esempi di revisione / discussione

In systems that take a user's pass-word/-phrase in order to derive the encryption key, what is the relationship between that password's strength and the key's strength?

Dipende interamente da come usi la password per derivare la chiave. Se stai solo eseguendo l'hashing o eseguendo l'hashing e salendo la tua password, la tua funzione potrebbe essere simile a questa:

generateKey(password, salt) := cryptoHash(password, salt)

Se avessi preso una tabella delle password più deboli probabilmente potrei calcolare i potenziali hash, e da lì avrei le possibili chiavi di crittografia. Quindi dato un message potrei romperlo con questa funzione:

crack(message, saltLen, weakPassList):=
    for salt in 0..saltLen:
        for weak in weakPassList:
            let k := generateKey(weak, salt)
            if decrypt(message, k) looks okay:
                return k

Questo potrebbe richiedere molto tempo per essere eseguito in base alla percentuale di saltLen e weakPassList ; tuttavia puoi memorizzare nella cache la k generata sopra in una tabella e provarli solo uno alla volta, per eliminare il fattore di generazione della chiave sperimentale.

Ci sono sicuramente modi migliori per generare una password, ma senza una specifica più dettagliata o un caso d'uso è difficile analizzare o raccomandare quale sia il metodo migliore.

2. Alternativa: chiave generata da password locale per uso interno nell'API di controllo della chiave di crittografia.

I know password strength matters in authentication; is it a moot point in encryption?

Ritengo che non vi siano differenze a meno che non si parli di un particolare metodo di generazione delle chiavi o di un altro caso d'uso specifico. Una chiave è una chiave.

Personalmente userò la password per generare una chiave di crittografia locale kLocal , utilizzata per oscurare una chiave di crittografia generata correttamente kMessage che può essere utilizzata per crittografare i messaggi per l'invio su canali non protetti.

In questo modo la password è solo un meccanismo di controllo degli accessi per filtrare gli utenti che possono digitare i comandi nel sistema e impedire loro di utilizzare le rispettive chiavi di crittografia (se non riescono a ottenere il giusto kLocal che non possono scoprire il contenuto di kMessage ). Questo è appropriato perché puoi utilizzare un'API sicura con, ad esempio, un bucket leaky , per impedire alle persone di eseguire attacchi di induzione della password sul computer locale.

Non è così semplice prevenire attacchi di indovinamento della password contro un messaggio di testo cifrato che è già stato inviato all'esterno! Rendendo il kLocal generato da password solo per l'uso interno, limitato all'API, hai vincolato il potere di calcolo effettivo dell'attaccante, il che è davvero una buona cosa per la sicurezza del software.

3. Entropia e aumentandola.

From my understanding, human-created passwords tend to have very low entropy, and that's why keys are derived from them.

Stai attento! L'entropia è solo la misura di quanto sia imprevedibile qualcosa. Se prendo alcuni valori con X quantità di entropia e li eseguo ciascuno attraverso una funzione nota ad un avversario, i risultati non possono avere più di X entropia. Cioè, se l'avversario può indovinare i valori originali e conosce anche la funzione per manipolarli / estenderli, avrà il tempo di indovinare i valori manipolati / estesi come farebbe con gli originali.

Non aumenti le dimensioni del dominio a meno che non aggiungiate ulteriori informazioni; e non stai aumentando l'entropia a meno che le informazioni che aggiungi non abbiano qualche entropia (è in qualche modo imprevedibile / segreto).

In systems that take a user's pass-word/-phrase in order to derive the encryption key, what is the relationship between that password's strength and the key's strength? I know password strength matters in authentication; is it a moot point in encryption?

Da wikipedia : Il livello di sicurezza della password è una misura dell'efficacia di una password nel resistere alle supposizioni e alle brute- attacchi di forza. Nella sua forma usuale, stima quante prove un utente malintenzionato che non ha accesso diretto alla password avrebbe bisogno, in media, di indovinarlo correttamente. La forza di una password è una funzione di lunghezza, complessità e imprevedibilità.

Quindi hai correttamente supposto che la forza della password sia rilevante per l'autenticazione. Se stiamo espandendo la nostra password per abbinare le dimensioni della chiave utilizzando una funzione di hash crittografica come SHA-1 , quindi la forza della password non è rilevante per la crittografia.

But while that 128-bit (or whatever) key may be all fine and dandy, what's to prevent an attacker from running lists of weak passwords through the key derivation function and then attempting to use the produced key to decrypt the message?

Il costo del tempo è il principale avversario di questo tipo di attacco a forza bruta.

Per wikipedia , Le risorse necessarie per un attacco di forza bruta crescono esponenzialmente con l'aumentare delle dimensioni della chiave , non in modo lineare. Sebbene le norme statunitensi sull'esportazione abbiano storicamente ridotto le lunghezze delle chiavi alle chiavi simmetriche a 56 bit (ad es. Data Encryption Standard), queste restrizioni non sono più in vigore, quindi i moderni algoritmi simmetrici utilizzano tipicamente più potenti chiavi da 128 a 256 bit.

La stessa pagina postula che la rottura di una chiave simmetrica a 128 bit (come AES) richiederebbe circa 10 ^ 18 joule di energia, o circa 30 gigawatt di potenza per un periodo di un anno. Questo è più di un centesimo della produzione mondiale di energia.

Ovviamente, l'unico modo per garantire la sicurezza dei dati codificati è semplicemente quello di impedire che cada in mani dannose.

My hunch is it has something to do with the computational cost.... but I AM curious if it's just as secure to use the letter "a" as the "password" as it is to use a super strong password.

Se l'utente malintenzionato può indovinare correttamente che la chiave di crittografia è derivata da una stringa semplice e indovina correttamente che la stringa di origine è "a" (o una password altrettanto stupida), allora sei nei guai. La scelta di buone password è importante.

Puoi anche utilizzare una tattica chiamata " salting " dove aggiungi qualche password casuale alla password . La stringa salt viene solitamente memorizzata nella stessa posizione della password e non viene crittografata, quindi non ti salverà se, per esempio, perdi un database di dati del cliente crittografati; tuttavia oscurerà il processo di derivazione della chiave se l'attaccante sta accedendo ai tuoi dati tramite l'autenticazione e eliminerà tutte le tabelle arcobaleno pre-calcolate generate con un sale diverso o senza sale.

Alcune cose possono essere messe in atto per frustrare gli attaccanti. La migliore pratica nell'uso delle funzioni di derivazione delle chiavi sta facendo rallentare deliberatamente la funzione di derivazione per impedire agli attacchi di forza bruta di rivelare il valore di input. L'uso di un sale (ad esempio 64 bit nelle moderne implementazioni) insieme al valore di input verrebbe utilizzato per complicare gli attacchi di dizionario. Questo approccio è indicato come "allungamento della chiave".

Andando oltre, il "rafforzamento chiave" utilizza la stessa tecnica, ma in aggiunta elimina in modo sicuro gli aggressori di sale e gli utenti a fare una ricerca di forza bruta per il sale, complicando ulteriormente gli attacchi di forza bruta. Una possibile implementazione in questo caso sarebbe quella di dividere il sale in una parte pubblica e una parte privata in cui il sale privato dovrebbe essere forzato brutale. Data la corretta immissione della password e la bruta di sale pubblica che forza il sale privato è fattibile. Tuttavia, se la forzatura bruta senza che la password originale debba calcolare anche il sale privato crea un ulteriore ostacolo.

Ovviamente, la forza del valore di input scelto (comunemente la password) è un fattore importante per la sicurezza.

Quello che capisco che vuoi dire è che qualcuno potrebbe usare un attacco di forza bruta sulla chiave direttamente (senza usare l'uso di parole d'ordine per generare chiavi diverse) più facilmente se fosse generato con una password debole piuttosto che con una strong ? Se questa è la tua domanda, allora la risposta nella stragrande maggioranza dei casi (e certamente con qualsiasi criptosistema implementato di recente) no. Le chiavi sono generate (come altre risposte hanno indicato) con gli hash fatti su una combinazione della tua password e (nella maggior parte dei casi) un "salt" casuale, che è solo un po 'casuale spazzatura generata al momento e conservata in bella vista. L'unico motivo per cui il sale è farlo è che le persone non possono pre-indovinare chiavi basate su password comuni. Anche senza di essa, tuttavia, la chiave generata anche da una password a 1 bit produrrà una chiave che è ancora veramente casuale. Questo perché i moderni algoritmi di hash sono molto efficaci nella produzione di rifiuti casuali da input anche molto piccoli. Sono progettati in modo tale da cambiare anche solo un bit in un hash completamente diverso. Nessuno sarebbe in grado di guardare una chiave del genere e pensare, oh, che uno è stato prodotto con una password debole.

Le password sono ancora, come altri hanno indicato, molto importanti. Key stretching , l'atto di prendere una password e di eseguirla attraverso un hash molte (forse migliaia) di volte per renderla computazionalmente difficile indovinare un sacco di password, può aiutarti, ma è soggetto a un valore ridotto dalla legge di Moore, proprio come tutto il resto. Con ciò intendo quello che ci vuole un sacco di tempo per fare oggi, non richiede necessariamente molto tempo domani. Ma non devi davvero preoccuparti, con qualsiasi sistema di crittografia moderno, che la chiave sia direttamente attaccabile. Scegli una buona password.