L'hashing della password funziona su resistenza preimage : il processo di hashing della password deve essere tale che non sia possibile computazionalmente trovare un input (una password) corrispondente a un dato output (l'hash), salvo provando un sacco di potenziali input e "sii fortunato". L'attacco "get lucky" è ancora un problema, perché le password sono scelte dagli utenti umani, che non sono così fantasiosi e casuali come si potrebbe desiderare; ecco perché abbiamo bisogno di più di una semplice funzione di hash (abbiamo bisogno di sali, abbiamo bisogno di lentezza; vedi questo ). Tuttavia, le collisioni non hanno alcun impatto sulla sicurezza dell'hash delle password. La capacità di generare collisioni a volontà non dà ulteriore potere di cracking all'attaccante.
Come altri hanno sottolineato, le collisioni possono essere utilizzate per attacchi in altre configurazioni che implicano firme . Questi sono scenari in cui l'aggressore può:
- generare collisioni di coppie di messaggi, con un controllo sufficiente sul formato di questi messaggi in modo che un messaggio appaia "innocente" e l'altro sia adatto agli obiettivi dell'attaccante;
- ha il messaggio dall'aspetto innocente firmato da una terza parte la cui funzione di firma inizia con l'hashing del messaggio "così com'è".
In entrambe queste condizioni, la terza parte produrrà la firma, che sarà valida (per quanto riguarda i verificatori delle firme) per i messaggi entrambi . È come avere il firmatario emettere una firma su un messaggio senza mostrarlo al firmatario. Una dimostrazione è stata fatta nel 2008 con i "messaggi" come certificati X.509 e il firmatario un'autorità di certificazione. Un'applicazione reale dello stesso concetto è stata eseguita nel malware di fiamma .
Un punto da realizzare è che sebbene le firme grezze siano vulnerabili alle collisioni, come spiegato sopra, possono essere protette dal fatto che il firmatario include una casualità all'inizio di ciò che firma. Nel contesto di certificati X.509 falsi, l'utente malintenzionato deve essere in grado di prevedere tutti i bit dei certificati fino alla chiave pubblica; questo include il numero di serie del certificato scelto dalla CA. Se la CA utilizza numeri seriali casuali di grandi dimensioni, l'attacco non viene applicato, anche se MD5 viene utilizzato come funzione hash. D'altra parte, le CA che utilizzano numeri seriali sequenziali o basati sul tempo sono prevedibili.
Un'altra preoccupazione per le collisioni riguarda le prove di sicurezza . Alcuni protocolli crittografici possono essere dimostrati sicuri in base ad alcune ipotesi specifiche sulle primitive crittografiche utilizzate nel protocollo; ad esempio, alcuni protocolli che utilizzano le funzioni hash possono essere sicuri fino a quando si suppone che la funzione hash sia resistente alla collisione o altre proprietà. Un esempio è HMAC . HMAC riutilizza una funzione di hash sottostante ed è stato progettato in modo da adattarsi alle funzioni hash del Merkle- Damgård persuasion , in particolare MD5 e l'intera famiglia SHA. Tale funzione di hash è costruita attorno a una "funzione di compressione" interna. HMAC è stato provato sicuro supponendo che la funzione di compressione si comporti come una funzione pseudocasuale .
Tuttavia, se la funzione di compressione di MD5 è un PRF, non è possibile calcolare collisioni per MD5 con costi inferiori a 2 64 in media. Sappiamo come produrre collisioni MD5 per molto meno di questo. Ciò implica che la funzione di compressione MD5 è non un PRF. Quindi questo invalida la prova di sicurezza su HMAC / MD5.
Questo non significa che sappiamo come rompere HMAC / MD5 con collisioni! È "solo" che qualsiasi garanzia matematica di sicurezza che abbiamo avuto è svanita come una rugiada mattutina sotto il spietato sole di mezzogiorno. A tale riguardo, le collisioni MD5 non sono uno strumento per essere sfruttate dall'attaccante, ma meritano comunque qualche attenzione.