Come generare in modo semplice ed efficiente chiavi diverse da una password?

Tecnicamente, PBKDF2 può produrre un output lungo arbitrario (è una Funzione di derivazione chiave ), ma presenta problemi: PBKDF2 utilizza HMAC su una funzione hash, che ha lunghezza di output k bit (ad es. k = 160 per il solito SHA-1). Se chiedi più output di quella dimensione, allora il costo computazionale aumenta rapidamente: se vuoi 320 bit, costerà il doppio di 160 bit.

Sfortunatamente, sebbene il PBKDF2 sia "rafforzato" per scoraggiare gli attacchi del dizionario, il costo dell'attaccante non aumenterà più velocemente. Si consideri ad esempio che si usi PBKDF2 / SHA-1 per produrre 256 bit di materiale chiave: 128 bit per la crittografia simmetrica, quindi 128 bit per un MAC. Come difensore (l'utente normale) devi ottenere tutti i 256 bit. L'attaccante, d'altra parte, non ha bisogno di tanto; può semplicemente produrre i primi 128 bit, a metà del costo , e vedere se la decifrazione produce dati non spazzatura.

Questo è un problema noto con PBKDF2. Si noti che lo stesso problema si presenterebbe se si utilizzava un'altra funzione di hashing della password due volte, con due diversi sali: si paga per l'hashing due volte, ma l'attaccante può ignorare una delle chiavi e quindi sarà due volte più veloce di te.

Se preferisci usare bcrypt, allora ti imbatti in un altro problema, che è che bcrypt non è un KDF; la sua dimensione di uscita è di 192 bit. Non piu. Il tempo di elaborazione non dipende dalla sua dimensione di output, poiché la sua dimensione di output è fissa.

Il metodo generico è eseguire una funzione di hashing della password, quindi espandi l'output con Funzione di derivazione chiave . Questo è ciò che @CodesInChaos suggerisce, con HKDF-Expand . Ci sono diversi KDF là fuori; di solito, per i miei progetti / proposte, faccio affidamento su HMAC_DRBG, da NIST SP800-90 e X9.62 (ad esempio in questo ). Idealmente, vuoi un KDF che sia ben controllato, cioè che sia stato investigato dai crittografi, e non hanno trovato nulla di negativo da dire (o, ancora meglio, hanno prodotto "prove di sicurezza").

Se sei di fretta e non hai bisogno di molto di materiale chiave, un metodo relativamente più semplice è quello di hash l'output della funzione di hash della password con SHA-512. Ciò ti darà 512 bit di materiale chiave.

Quando si utilizza PBKDF2 è possibile specificare la lunghezza di output della chiave di uscita. Se si desidera generare due chiavi a 256 bit, si genera un output a 512 bit e lo si divide. Si consiglia di utilizzare un sale lungo, in modo che l'entropia di entrambi i tasti sia effettivamente 512 bit.

Generate two keys using the same password, but different salts? This is the correct answer given sufficiently long and [cryptographically] random salts. CodesInChaos makes two good points - don't exceed the natural output size of your underlying hash (160 bits for PBKDF2-HMAC-SHA-1, 512 bits for PBKDF2-HMAC-SHA-512, etc.), and a 128 bit salt is probably fine, especially if you're using 128 bit encryption.

Per RFC2898, una delle specifiche PBKDF2 / RFC2898 / PKCS # 5 , sezione 4.1: "Un sale nella crittografia basata su password tradizionalmente è servito lo scopo di produrre un grande insieme di chiavi corrispondenti a una determinata password, tra le quali una è selezionata casualmente in base al sale. " Il resto di 4.1 entra in dettaglio su altre considerazioni per generare più sali, in particolare su come le altre parti possono facilmente dire quale sale dovrebbero usare per quale operazione. *

* vale a dire. una risposta (non esplicitamente citata nella RFC) è quella di generare sali tale che il sale che inizia con AA è per la prima operazione, il sale che inizia con AB per il secondo, AC per il terzo, ecc .; aggiungi un primo byte non casuale al sale per un "indicatore di posizionamento", purché il resto del sale sia crittograficamente casuale e abbastanza lungo.