Crittografia e HMAC con la stessa password

Ecco alcuni punti deboli (il primo è il più serio):

• Se non si include la crittografia IV nell'input di HMAC, gli autori di attacchi potrebbero modificare la IV e indurre una modifica corrispondente nel messaggio senza essere rilevati. Allo stesso modo, l'attaccante potrebbe modificare SALT1 o ITERATIONS1; l'HMAC sarebbe ancora in grado di eguagliare, ma si otterrebbe spazzatura al momento della decifrazione. Per encrypt-then-MAC, DEVE calcolare il MAC su tutto che contribuisce alla decrittografia. Nella descrizione, l'input HMAC dovrebbe essere una codifica di una struttura contenente i dati crittografati, ma anche l'IV, il SALT1, ITERATIONS1 e qualsiasi identificatore simbolico per gli algoritmi utilizzati (nel caso in cui si desideri prendere alcune disposizioni per l'agilità dell'algoritmo) .

• PBKDF2 è una funzione di hashing della password . È reso lento con molte iterazioni. Dal momento che la lentezza influisce allo stesso modo su un attaccante e un difensore, non è possibile impostare il numero di iterazioni arbitrariamente alto. Nella tua descrizione, il difensore deve usare le due chiamate PBKDF2 nell'uso normale, pagando così entrambe le cose; mentre l'attaccante può eseguire il suo attacco di dizionario su entrambi. Quindi il costo per il difensore è ITERATIONS1 + ITERATIONS2, mentre il costo per l'attaccante è solo il più piccolo dei due. Questo è un vantaggio per l'attaccante.

• PBKDF2 non è il migliore della classe; può essere eseguito in modo molto efficiente su una GPU. Bcrypt sarebbe meglio (vedi questa risposta ).

• Si sta facendo affidamento sul fatto che PBKDF2 si comporta come una sorta di "oracolo casuale" per quanto riguarda il valore del sale. Succede che nel caso di PBKDF2, questo è plausibile (PBKDF2 è una catena di HMAC nidificata, a partire dal sale). Tuttavia, questa non è una proprietà molto studiata e non si può contare su di essa solo per uno schema di derivazione della chiave basato su password. Sarebbe più sicuro usare le primitive crittografiche nel modo in cui erano destinate, perché la sicurezza viene dal controllo e l'uso esotico dell'algoritmo non è stato, per definizione, rivisto estensivamente dai crittografi.

Uno schema migliore dovrebbe eseguire una funzione di hashing della password (ad esempio, bcrypt), con un numero di sale e un conteggio di iterazione; e quindi espande il risultato con una funzione di derivazione chiave (una veloce, ad esempio < a href="http://tools.ietf.org/html/rfc5869"> HKDF ) in una sequenza di byte che dividerei in una chiave di crittografia e una chiave MAC. Questo è, per inciso, come sono fatte le cose in SSL. Se sei di fretta e non vuoi implementare un KDF extra, puoi usare in molti casi un semplice hash: calcola SHA-256 sull'output bcrypt, ottenendo 256 bit; i primi 128 bit sono per la crittografia, l'altra metà per il MAC.

In generale, , è preferibile utilizzare la crittografia autenticata . CCM è un tentativo iniziale in modalità AE; le scelte migliori sono EAX e GCM . Quest'ultimo sta rapidamente diventando uno standard per queste cose ed è stato benedetto dal NIST. È supportato in SSL / TLS (dal TLS-1.2) ed è disponibile in alcune librerie diffuse (ad esempio OpenSSL).