Perché non mescolare gli hash?

Mi è stato chiesto di dare al mio commento una risposta, quindi ecco qui.

Fondamentalmente, ho detto che bcrypt, scrypt e pbkdf2 non sono essi stessi hash, ma sono le funzioni di derivazione chiave di KDF. I KDF sono basati su algoritmi HMAC, che a loro volta sono basati su algoritmi di hashing unidirezionali come SHA-256 per generare i valori digest del messaggio.

C'è già un notevole mixaggio, agitazione e agitazione coinvolti nell'ottenere un valore da un KDF.

Anche se il mixaggio dell'output di più KDF non indebolisce la sicurezza generale, sembra probabile che non lo migliori materialmente.

Quando provi a password di hash , l'autore dell'attacco può usa sempre lo stesso tipo di hardware del difensore. Ciò che l'attaccante cerca è di fare meglio, usando hardware specializzato che gli consenta di usare hash N password potenziali per un costo inferiore rispetto a se stesse usando l'hardware del difensore. Il costo totale include il costo di acquisto dell'hardware, il costo di sviluppo del relativo software e quindi il costo di esecuzione dell'hardware, che sostanzialmente equivale all'elettricità utilizzata (per alimentare l'hardware e per rinfrescarlo). Per un attaccante serio, il costo del potere domina.

Ogni volta che c'è qualche operazione che l'attaccante può fare meno del difensore, l'attaccante vince. Un punto importante è che il cracking della password è un imbarazzante problema parallelo : per definizione, l'autore dell'attacco ha molti potenziali password da provare.

Supponete di sovrapporre tre funzioni hash distinte Hash1 , Hash2 e Hash3 . Ciò significa che il difensore deve avere tutte e tre le implementazioni a portata di mano, tutte in esecuzione sul suo server. L'attaccante, d'altra parte, può avere una programmazione migliore: può (dire) hash un milione di potenziali password con Hash1 e salvare i risultati in un buffer; quindi passare l'hardware a qualcosa che applica Hash2 , ed eseguirlo oltre il milione di uscite salvate dal passaggio precedente, salvando di nuovo le uscite Hash2 in un buffer; infine, cambio di nuovo l'hardware, con Hash3 .

Questo tipo di "commutazione hardware" è particolarmente rilevante quando si utilizza FPGA : ogni "commutazione" è una riprogrammazione dello stesso hardware reale ed è questione di pochi secondi al massimo. Usando tale schedulazione e buffering, il costo di "commutazione" è trascurabile.

Può essere usato anche come pipeline: se l'attaccante ha creato tre macchine specializzate, una per Hash1 , una per Hash2 e una per Hash3 , allora può eseguire Hash1 sulla prima password potenziale, quindi invia l'output alla macchina che calcola Hash2 . Mentre la seconda macchina calcola Hash2 , la prima macchina può calcolare Hash1 su un'altra password potenziale. E così via. In pratica, l'attaccante può mantenere tutte le sue macchine specializzate in piena occupazione in qualsiasi momento, ridendo così dei tuoi tentativi di "aumentare la forza".

Inoltre, se ci sono tre funzioni hash distinte da implementare e solo una di esse può essere ottimizzata con hardware specializzato, l'hacker ottiene comunque una vittoria ottimizzandone quella. Per dire le cose in modo grossolano, se si esegue la cascata di bcrypt, scrypt e SHA-256, l'autore dell'attacco utilizzerà un PC per i primi due e una GPU per SHA-256 e quindi eviterà circa 1/3 del costo. / p>

Per riassumere, l'intuizione che "la miscelazione di un insieme di algoritmi di hash diversi dovrebbe fornire ulteriore forza" è sbagliata. Fa il contrario. Tale mixaggio aumenta i costi di sviluppo e di utilizzo per il difensore, mentre non rallenta l'attaccante (che ha molto parallelismo con cui trarre vantaggio), e aumenta le opzioni di ottimizzazione dell'attaccante.

(Tutto questo viene detto senza parlare di aspetti pratici, come la gestione dei singoli sali per tutte le funzioni in cascata e i pericoli della crittografia fatta in casa.)

Per copiare la mia risposta a una domanda simile su progs.SE:

the problem with

hash1(hash2(hash3(...hashn(pass+salt)+salt)+salt)...)+salt)

is that this is only as strong as the weakest hash function in the chain. for example if hashn (the innermost hash) gives a collision the entire hash chain will give a collision (irrespective of what other hashes are in the chain)

a stronger chain would be

hash1(hash2(hash3(...hashn(pass+salt)+pass+salt)+pass+salt)...)+pass+salt)

here we avoid the early collision problem and we essentially generate a salt that depends on the password for the final hash

and if one step in the chain collides it doesn't matter because in the next step the password is used again and should give a different result for different passwords

L'uso di diversi algoritmi di hash non ti darà più entropia, ma meno. Immagino che tu abbia sentito l'espressione «La sicurezza non è più strong del punto più debole», lo stesso vale anche qui. L'entropia di questo non sarà superiore a quella fornita dall'algoritmo più debole.

Tuttavia, l'hashing della password con lo stesso algoritmo più volte ti darà più sicurezza. Ma usa un algoritmo di hash strong pochi round piuttosto che un algoritmo debole molti round. Esempio questo è più sicuro:

sha512 ( sha512 ( sha512 ( password + salt )))

Than:

sha1 ( sha1 ( sha1 ( sha1 ( sha1 ( sha1 ( ... sha1 ( password + salt ) ... ))))))

Vedo che ci sono persone che non ci credono e vogliono che lo provassi. Facciamo un esempio. Ho scelto tre algoritmi di hashing, SHA256, SHA1 e MD5.

• SHA256 produce output a 256 bit
• SHA1 produce un output a 160 bit
• MD5 produce output a 128 bit

Quindi, se abbiamo:

sha256 ( sha1 ( md5 ( password + salt )));

Prima la password e il sale sono sottoposti a hash con MD5, l'output sarà grande 128 bit, quindi le possibilità totali dell'uscita MD5 sono 2 ^ 128. Quindi la somma MD5 viene hash con SHA1, ma non è necessario hash tutte le possibilità, solo il 2 ^ 128 come output MD5. Quindi la somma SHA1 viene sottoposta a hash con SHA256, ma nuovamente. Non è necessario hash tutte le possibilità di SHA256, solo le 2 ^ 128 possibilità che MD5 produce. Quindi questo algoritmo di hash può produrre solo un output con entropia di 2 ^ 128, come l'MD5. E MD5 ha molteplici vulnerabilità, quindi la forza effettiva è inferiore a 2 ^ 128.

Gli hash di missaggio di solito danno come risultato la sicurezza dell'hash più debole della catena, ovvero:

• Prima resistenza all'antimerizzazione
• Seconda resistenza preimage
• Resistenza alle collisioni

Invece di mescolare gli hash, la potenza della CPU di solito è meglio indirizzata all'hashing con più byte.

In altre parole, se l'hashing con due algoritmi richiede N Joules di lavoro e comporta meno sicurezza, usa SHA512 invece di SHA256 e sarai più sicuro.

Gli hash non dovrebbero essere impilati; piuttosto, il risultato di più hash dovrebbe essere XORed insieme. Un tale primitivo (che gli XORs combinano più funzioni di hash strong credute) può essere usato nel loop di PBKDF o simile per ottenere risultati molto superiori alle funzioni di hash di stacking. Ciò che deve essere preso in considerazione nell'analisi costi-benefici è che tale protocollo richiede un sacco di lavoro aggiuntivo da attuare da parte dei bravi ragazzi, e non ci sono prove che i cattivi acquisti possano interrompere SHA-256.

Se cambi da:

myhash = Hash1(Hash2(Hash3(password ^ salt)))

... a ...

myhash = Hash1(password + salt + Hash2(password + salt + Hash3(password ^ salt)))

... quindi potresti aver ridotto il rischio di una collisione di Hash1 ...