Un mio specifico esempio riguarda la probabilità di collisione, dove ho due semplici testi A e B che voglio usare per l'hash MD5.
Data la funzione di hash crittografica H e il seguente:
A' = H(A)
B' = H(B)
A'' = H(H(A))
B'' = H(H(B))
è la probabilità di A'' e B'' collisione superiore a quella di A' e B' ?
Dovrebbe essere studiato se tale azione produrrebbe o meno una collisione nella pratica, ma si può considerare che un hash MD5 ricorsivo è ancora solo un hash MD5 alla fine. Stai eseguendo l'hash solo su 32 bit di dati (l'output del tuo n-1) anziché su n bit di dati. Quindi, considerando che l'algoritmo hash è pseudo-casuale, potresti invece chiedere se le collisioni sono più o meno probabili su 32 bit di dati rispetto a una dimensione variabile.
Le collisioni dovrebbero essere ugualmente improbabili in entrambi i casi, dato che sono sempre improbabili con un buon algoritmo. Per quanto riguarda la capacità di forzare una collisione, potresti sconfiggere i metodi conosciuti, ma in linea di principio dovrebbe essere lo stesso, se il tuo nuovo algoritmo fosse stato studiato.
Infine, devi considerare quale è il significato della tua paura delle collisioni. A quanto ho capito, le collisioni consentono di inserire una password invece dell'hash della password, un'altra password e lo stesso hash. Nei certificati, significa la possibilità di generare una nuova chiave privata per la crittografia dei dati (ad esempio la password del certificato). Quindi, se gli hash di accesso sono stati compromessi, le collisioni potrebbero consentire loro di entrare nel tuo sito, ma di non conoscere esattamente le password dell'utente. E questo sarà principalmente l'uso crittografico di un algoritmo has - per nascondere la password o altri dati di origine. In questo caso, è meglio eseguire l'hashing più volte poiché aumenterà la CPU necessaria per indovinare gli hash in testo normale. Puoi presumere che il tuo sito sia stato violato, che tutte le tue informazioni siano anche divulgate, e quindi non resta la grande necessità che un utente malintenzionato si colleghi nuovamente al tuo sito con una password in conflitto.
La possibilità di autenticare una password o altri dati è ridotta dalle collisioni, ma di nuovo è improbabile in generale e quindi anche ricorsivamente improbabile poiché ognuna ha il maggior numero di collisioni del solo hash, che è lo stesso di un hash. Il sottoinsieme di dati (il risultato dell'n - 1o hash) non dovrebbe aumentare il rischio di collisioni con una funzione hash pseudo-casuale. Se non è davvero casuale, le collisioni aumentano sicuramente, ma questo non le rende necessariamente più facili da trovare o creare, anche se perderete un po 'di iniquità. Con un buon hash, questo dovrebbe essere minimo e non preoccupante per la difficoltà computazionale ottenuta dalla ricorsione.
Facendo il numero di volte in cui l'hashing ti offre più casualità ed entropia.
La ragione principale è la protezione dagli attacchi di forza bruta. Stai aggiungendo un fattore di lavoro per rallentare le prove delle possibili chiavi. Prendi un passcode di 4 cifre - ci sono 10.000 password possibili, e puoi ottenerle tutte incrementando da 0 a 9999 di 1. Se usi una funzione di derivazione chiave come PBKDF2, devi anche aggiungere il passcode X numero di volte (generalmente Da 2.000 a 50.000), aumenta la quantità di lavoro che devi fare per ottenere la chiave.
Un altro motivo è l'allungamento della chiave. Invece di usare una chiave a 4 cifre, stai utilizzando una chiave più lunga per la crittografia (anche se la ottieni con un singolo hash).
Infine, considera il caso in cui l'hash viene rivelato per qualche motivo. In una singola operazione di hash, è possibile cercare il codice di accesso corrispondente all'hash per una singola operazione di hash. Farlo più volte impedisce una facile ricerca del passcode originale. È utile quando gli utenti utilizzano lo stesso passcode in più posizioni.