Quali sono gli svantaggi dell'uso di un approccio di allungamento della chiave banalmente semplice come l'esempio di Python di sotto, rispetto a qualcosa come PBKDF2? Lo scopo è quello di indurire un file crittografato con AES contro il brute-forcing.
Ci sono problemi critici con il modo banale? Non è disponibile l'implementazione PBKDF2 nella lingua con cui sto programmando.
for _ in range (100000):
key = hashlib.sha256(key).hexdigest()
L'argomento di sicurezza per PBKDF2 è migliore di quello per la tua proposta. Ciò non significa che la tua proposta sia meno sicura, solo che PBKDF2 è più facile da giustificare.
Questo perché PBKDF2 incorpora tre ulteriori idee oltre alla tua proposta di iterazione. Primo, PBKDF2 incorpora esplicitamente un sale, mentre il tuo esempio no. Anche se tu supponessi implicitamente che key sarebbe qualcosa come salt + password , una password scrambler dovrebbe davvero prendere la password e saltare come argomenti separati.
In secondo luogo, PBKDF2 non itera una funzione pubblica di hash come SHA-256, ma una funzione pseudocasuale ("PRF") come HMAC-SHA-256, digitato con la password. Questo è un punto teorico molto sottile, ma ciò significa che PBKDF può funzionare con funzioni più deboli di una funzione di hash in piena regola come SHA-256.
In terzo luogo, PBKDF2 non concatena solo gli output del PRF, ma anche gli XOR delle sue uscite. Questa è una protezione (forse paranoica) contro i PRF deboli che hanno cicli brevi quando applicati ai loro output.
PBKDF2 è in realtà piuttosto semplice. È abbastanza semplice che i laici non riescano a rovinarlo. Se la tua lingua e libreria hanno SHA-256 hanno probabilmente anche HMAC-SHA-256, ma se non è così facile da implementare. Quindi dovresti solo dargli una possibilità: è meglio attenersi a tecniche standard e ben collaudate piuttosto che cucinare da soli.
Nota finale: l'output di una funzione di hash è dati binari e in realtà dovrebbe essere trattato come tale. Cioè, il tuo uso di hexdigest nel tuo esempio è dispendioso e non favorevole a un codice di buona qualità; i dati dovrebbero essere elaborati il più possibile nel suo tipo nativo! (L'utilizzo di digest esadecimali ti darebbe anche un'implementazione PBKDF2 errata.)
Da wikipedia: Key Stretching :
... are used to make a possibly weak key ... more secure against a brute force attack by increasing the time it takes to test each possible key
Poiché gli hash come SHA-2 sono progettati per lo stretching semplice della chiave di velocità usando solo l'hash, non rallentare realmente un attaccante che cerca di forzare un tasto basato sull'input debole. I KDF come PBKDF2 sono invece progettati per rallentare davvero l'aggressore essendo lenti a loro volta.
Sebbene l'esempio faccia molte iterazioni per rallentare il calcolo, un utente malintenzionato potrebbe creare una volta un database di tutti gli input deboli interessanti e i relativi output e utilizzare successivamente questi valori precalcolati in più attacchi brute-force invece di ricalcolare tutti i valori al momento di attacco. Ecco perché algoritmi come PBKDF2 utilizzano in aggiunta un sale per aumentare notevolmente la memoria necessari da tale database e il tempo per crearlo e quindi renderlo impraticabile.
There is no PBKDF2 implementation available in the language I am programming with.
Se la lingua offre già un modo per calcolare un hash e sei disposto a creare un po 'di KDF, allora implementando PBKDF2 o altro KDF ben progettato invece della tua idea non dovrebbe essere troppo difficile.
Leggi altre domande sui tag brute-force key-stretching