Gli hash hash devono essere in collisione o no?

1

Dato che lo stretching chiave si riduce fondamentalmente all'hash hash più e più volte (dove sale, pepe e password individuano la funzione hash, ma il principio rimane lo stesso), mi chiedo di questa domanda.

Da un lato, gli hash dovrebbero essere il più possibile esenti da collisioni. Per gli stessi hash, ciò è teoricamente realizzabile a causa della stessa lunghezza, ma ciò darebbe l'esistenza di una mappa biiettiva, cioè per ogni hash h si potrebbe dare un altro hash h₂, il cui hash è l'hash originale di nuovo, quindi tu può invertire l'hash. Quindi potresti "semplicemente" usare l'inversione per invertire l'intera catena di hash e creare una password valida - anche peggio, se sale / pepe e password influenzano la derivazione della chiave allo stesso modo, questo potrebbe rendere inutilizzabile la salatura dal momento della creazione la password potrebbe compensare la sua influenza.

D'altra parte, se gli hash si scontrano, questo significa che alcuni hash sono più sicuri di altri - alcuni hash non possono essere ottenuti tagliando un altro hash, ma altri hash possono essere ottenuti da più hash. E questi hash sarebbero attrattori ed è molto più probabile che si verifichino dopo molti cicli di hashing rispetto a quelli non ottenibili, riducendo efficacemente il potenziale spazio delle chiavi.

Quindi, quale di queste due possibilità è peggiore, e quale è il caso reale nella realtà? Poiché la scelta della password e di sale / pepe modifica la funzione di hashing, la risposta dipende da questo? Questo problema può essere risolto concatenando l'intera catena di hash invece di quella finale? (Se questo non ha già un nome, posso proporre hash cat?)

    
posta Tobias Kienzler 08.03.2013 - 14:24
fonte

2 risposte

1

Poiché le funzioni di hash hanno uno spazio di input molto più ampio dello spazio di output, le collisioni sono una caratteristica normale, e ci si aspetta che ogni output possibile corrisponda a un sacco di matching ingressi.

Di norma, le collisioni non rappresentano un problema per l'hashing della password . Il paragrafo precedente significa che, per ogni output di hash (in particolare quello memorizzato nel database del server), ci sono molte password corrispondenti che sono tutte equivalenti. Tuttavia:

  • per trovare una singola password che corrisponda all'output memorizzato, devi interrompere resistenza preimage della funzione di hash;
  • per trovare una seconda password che restituisce lo stesso hash di una password conosciuta, devi interrompere la seconda resistenza di preimage della funzione di hash.

Una funzione di hash "crittograficamente sicura" con un output di n bit dovrebbe offrire resistenza 2 n a entrambi i tipi di attacchi, quindi nessun vero problema qui. Conoscere una collisione in abstracto non dà molto potere a nessun attaccante: l'attaccante può usare una determinata password, e ha un "spare" con lo stesso effetto; quindi cosa?

Per quanto riguarda la riduzione dello spazio quando si itera la funzione, vedere questa risposta precedente . Riepilogo: si verifica la riduzione dello spazio, ma non al di sotto di uno spazio interno di dimensioni 2 n / 2 , che inoltre:

  • richiede un grande sforzo per essere effettivamente raggiunto;
  • non può essere caratterizzato in modo efficiente (non puoi facilmente sapere se un dato valore fa parte di quello spazio interno o meno).

Usa SHA-256 e sii felice.

    
risposta data 08.03.2013 - 15:30
fonte
1

Se qualsiasi livello dell'hash collide, anche tutti i livelli aggiuntivi si scontreranno. Lo spazio è così grande, tuttavia, che non avrai spesso problemi se usi un hash crittograficamente sicuro.

Ad esempio, se hai cancellato ABC e ottenuto 123 e poi hai cancellato 123 per ottenere 456. Se hai cancellato DEF e ottenuto 123, il tuo secondo turno di hashing sarebbe un hashing la stessa cosa del tuo primo esempio. Gli spazi per le chiavi sono così grandi che non è un problema pratico. Il problema potrebbe anche essere mitigato tagliando il risultato delle ultime 2 iterazioni (quindi l'hash di ABC123 è probabilmente diverso dall'hash di DEF123).

    
risposta data 08.03.2013 - 15:37
fonte

Leggi altre domande sui tag