Il "tasto MD5" descritto in RFC 1828 può essere riassunto come segue: per la chiave K e data D , il valore MAC è MD5 ( K || D || K ) (in la RFC, K viene prima riempita con un multiplo di lunghezza di 512 bit, ma non cambia sostanzialmente le cose qui). Per quanto ne so, non vi è alcuna debolezza nota a questa costruzione, ma non c'è nemmeno molta analisi di sicurezza.
HMAC è stato progettato per fornire sicurezza se utilizzato con una funzione di hash che si basa su Merkle-Damgård construction . È stato dimostrato che SE la "funzione di compressione" interna della funzione hash agisce come una famiglia di funzioni pseudocasuali , quindi HMAC è sicuro. Non conosciamo alcuna prova di sicurezza simile per la costruzione di "hash con chiave". In questo senso, crediamo di più nella sicurezza di HMAC che nella sicurezza dell '"hash con chiave".
Se le funzioni di hash erano "perfette" in un senso che si riferisce alla nozione di oracoli casuali , allora l'hash con chiave sarebbe "ovviamente" sicuro, come un certo numero di altre costruzioni, ad es h ( K || D ). Quest'ultimo esempio ricade sull'aggressione lunghezza> quando la funzione hash utilizza la costruzione MD (che è il caso per MD5 ma anche SHA-1, SHA-256 ...); questo non ha un impatto diretto sulla "chiave cancellata" da RFC 1828, ma è sufficiente per dimostrare che le funzioni hash basate su MD sono non perfette nel senso accennato in precedenza, e quindi la sicurezza di qualsiasi costruzione MAC non può essere semplicemente assunto. Abbiamo bisogno di ulteriori dettagli e con HMAC abbiamo questi dettagli.
Alcune note extra:
-
L'attacco di estensione della lunghezza non contraddice la sicurezza classica della funzione di hash , ovvero la resistenza a preimmagini, seconde pre-immagini e collisioni. In particolare, SHA-256 e SHA-512 sono "ritenuti sicuri" e tuttavia rientrano nell'ambito dell'estensione di estensione.
-
Le collisioni non sono un problema qui e, più in generale, non sono un problema nelle costruzioni che utilizzano input sconosciuti per l'utente malintenzionato (come di consueto per MAC, a causa della chiave). Sappiamo come produrre collisioni per MD5 in modo molto efficiente; ma non sappiamo come attaccare HMAC / MD5 o persino il "keyed MD5". (È possibile progettare un MAC contrived che usa MD5 ed è debole a causa delle collisioni MD5, ma non è questo il caso per HMAC o per il "keyed MD5" di cui stiamo discutendo qui.)
-
Viceversa, mentre le collisioni non si applicano a HMAC, la semplice esistenza di metodi efficienti per calcolare collisioni MD5 dimostra che la funzione di compressione interna di MD5 è non un PRF, e quindi l'HMAC la prova di sicurezza non si applica a HMAC / MD5. Questo è un peccato dal momento che l'intero punto di utilizzo di HMAC e non il "keyed hash" è quello di beneficiare della prova di sicurezza. Fai attenzione, tuttavia, che la mancanza di prove di sicurezza non significa che gli attacchi siano possibili; solo che se viene trovato un attacco, allora non sarebbe in contraddizione con la prova di sicurezza HMAC generica.