Mi sono reso conto che la seguente implementazione non è veramente sicura:
$pb = pbkdf2('sha256', $_POST['pass'], "enc_salt", 100, 100);
$d = openssl_decrypt ($data['container'],'aes-192-cbc', $pb, true, $data['iv']);
In effetti, dovrei usare un unico salt per $ pb invece di "enc_salt", non dovrei?
Inoltre, posso semplicemente utilizzare lo stesso IV per PBKDF: generare la chiave e crittografare effettivamente il contenuto?
Il sale è qui per prevenire la condivisione dei costi da parte degli aggressori. Se due password sono state sottoposte a hash con la stessa quantità di sale, un utente malintenzionato potrebbe eseguire l'hashing di una password potenziale utilizzando tale valore salt e confrontare l'output con le versioni hash delle due password; in altre parole, l'attaccante può attaccare le due password hash per il costo di attaccarne una. Questo si riduce: se ci sono 1000 password hash, tutte con lo stesso sale, l'attaccante ne ottiene 999 "gratuitamente".
Questo tipo di condivisione dei costi può assumere diverse forme, una delle quali è una tabella precalcolata (e uno specifico tipo di tabella è chiamato "tabella arcobaleno"). In generale, la condivisione dei costi è un'istanza di parallelismo (con l'appropriato distorsione spazio-temporale).
Dovresti sforzarti di riutilizzare i valori salati il più raramente possibile; se possibile, mai. Nel tuo caso, memorizzerai il sale insieme al file crittografato; e ogni file avrebbe il suo valore di sale (anche se due file usano la stessa password, ognuno dovrebbe avere il proprio sale).
Se ogni file ha il suo valore di sale, allora puoi fare una delle seguenti azioni per il IV:
La seconda e la terza opzione sono sicure solo se stai generando un nuovo salt per ogni file, in uno spazio abbastanza grande che le collisioni non si verificano nella pratica. Altrimenti, potresti finire con il riutilizzo IV, che è un peccato. In particolare, ciò che è realmente Bad TM sta utilizzando il doppio IV con lo stesso tasto . Se ogni file ha una propria chiave (poiché la chiave proviene dall'elaborazione della password con il sale e ogni file ha il proprio sale), allora un IV fisso va bene.
Ad ogni modo, se hai bisogno di crittografia, è probabile che sia necessaria anche l'integrità controllata, che richiede un MAC . Assemblare correttamente la crittografia e un MAC è difficile . Il modo corretto è utilizzare una modalità di crittografia che già fa il lavoro in un modo che renda felici i crittografi. In pratica, usa 'aes-192-gcm' , non 'aes-192-cbc' (o 'aes-128-gcm' : 128 bit sono già abbastanza buoni, e sarà leggermente più veloce).
Si noti che la lunghezza IV effettiva per GCM è di 12 byte.
Lo scopo principale del sale è di proteggere dagli attacchi dei tavoli arcobaleno. Esistono diversi scenari:
Pertanto si consiglia di utilizzare sempre un sale diverso per ogni password.
Di solito, il sale non è considerato una risorsa segreta e può quindi essere salvato in forma non criptata nel database. L'unico scopo è rendere l'uso di Rainbow Tables non fattibile. Non sono un esperto di IV, ma per quanto ne so, gli IV dovrebbero essere segreti, e probabilmente non è una buona idea se gli IV siano archiviati nel database in forma non criptata. Pertanto, non consiglierei di usare l'IV come sale.
Leggi altre domande sui tag encryption aes pbkdf2