El "MD5 con llave" descrito en RFC 1828 se puede resumir de la siguiente manera: para la tecla K y datos D , el valor MAC es MD5 ( K || D || K ) (en el RFC, K se rellena primero con un múltiplo de longitud de 512 bits, pero aquí no cambia sustancialmente las cosas). Que yo sepa, no hay debilidad conocida en esa construcción, pero tampoco hay mucho análisis de seguridad.
HMAC se ha diseñado para proporcionar seguridad cuando se utiliza con una función hash que se basa en Merkle–Damgård construction . Se ha demostrado que SI la "función de compresión" interna de la función hash actúa como una familia de funciones pseudorandom , entonces HMAC es seguro. No conocemos ninguna prueba de seguridad similar para la construcción del "hash codificado". En ese sentido, creemos más en la seguridad de HMAC que en la seguridad del "hash codificado".
Si las funciones hash fueran "perfectas" en un sentido que se relaciona con la noción de oracles aleatorios , entonces el hash con clave sería "obviamente" seguro, como una serie de otras construcciones, por ejemplo, h ( K || D ). Este último ejemplo recae en el ataque de extensión de longitud cuando la función hash usa la construcción MD (que es el caso de MD5 pero también SHA-1, SHA-256 ...); esto no afecta directamente al "hash codificado" de RFC 1828, pero es suficiente para demostrar que las funciones de hash basadas en MD no son perfectas en el sentido aludido anteriormente, y por lo tanto la seguridad de cualquier construcción de MAC no puede simplemente asumirse. Necesitamos más detalles, y con HMAC tenemos estos detalles.
Algunas notas adicionales:
-
El "ataque de extensión de longitud" no contradice la seguridad clásica de la función hash , es decir, resistencia a Preimágenes, segundas preimágenes y colisiones. En particular, SHA-256 y SHA-512 se consideran "seguros" y, sin embargo, están incluidos en el alcance del ataque de extensión de longitud.
-
Las colisiones no son un problema aquí, y, más generalmente, no son un problema en construcciones que usan entradas desconocidas para el atacante (como es habitual en MAC, debido a la clave). Sabemos cómo producir colisiones para MD5 de manera muy eficiente; pero no sabemos cómo atacar HMAC / MD5 o incluso el "MD5 con clave". (Es posible diseñar un MAC ideado que use MD5 y sea débil debido a las colisiones de MD5, pero no es el caso de HMAC ni del "MD5 codificado" que estamos discutiendo aquí.)
-
Por el contrario, mientras que las colisiones no se aplican a HMAC, la mera existencia de métodos eficientes para calcular las colisiones MD5 demuestra que la función de compresión interna de MD5 es no un PRF, y por lo tanto el HMAC La prueba de seguridad no se aplica a HMAC / MD5. Es una pena, ya que el objetivo principal de usar HMAC y no el "hash codificado" es beneficiarse de la prueba de seguridad. Sin embargo, tenga en cuenta que la falta de pruebas de seguridad no significa que los ataques sean posibles; solo que si se encuentra un ataque, entonces no contradeciría la prueba de seguridad HMAC genérica.