Panoramica
- Alcuni esempi di revisione / discussione.
- Alternativa: chiave generata da password locale per uso interno nell'API di controllo della chiave di crittografia.
- 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).