El hash de contraseña funciona en resistencia de preimagen : el proceso de hashing de contraseña debe ser tal que no sea computacionalmente posible encontrar una entrada (una contraseña) que coincida con una salida determinada (el hash). Un montón de insumos potenciales y "tener suerte". El ataque "tener suerte" sigue siendo una preocupación, porque las contraseñas son elegidas por usuarios humanos, que no son tan imaginativos y aleatorios como se podría desear; Es por eso que necesitamos algo más que una simple función hash (necesitamos sales, necesitamos lentitud, consulte esto ). Sin embargo, las colisiones no tienen ningún impacto en la seguridad del hashing de contraseñas. La capacidad de generar colisiones a voluntad no le da al atacante un poder extra de craqueo.
Como han señalado otros, las colisiones se pueden utilizar para ataques en otras configuraciones que involucran firmas . Estos son escenarios donde el atacante puede:
- generar pares de mensajes en conflicto, con suficiente control sobre el formato de estos mensajes para que un mensaje parezca "inocente" y el otro se adapte a los objetivos del atacante;
- haga que el mensaje de apariencia inocente esté firmado por un tercero cuya función de firma comience con un hashing del mensaje "tal como está".
Bajo estas dos condiciones, el tercero producirá la firma, que será válida (en lo que respecta a los verificadores de firmas) para los mensajes de ambos . Esto es como hacer que el firmante emita una firma en un mensaje sin mostrarla al firmante. Se ha realizado una demostración de realizada en 2008 con los "mensajes" siendo certificados X.509 y el firmante una Autoridad de Certificación. Se realizó una aplicación en la vida real del mismo concepto en el malware Flame .
Un punto a destacar es que aunque las firmas sin formato son vulnerables a las colisiones, como se explicó anteriormente, pueden estar protegiendo si el firmante incluye cierta aleatoriedad al comienzo de lo que firma. En el contexto de los certificados X.509 falsos, el atacante debe poder predecir, todos los bits de los certificados hasta la clave pública; esto incluye el número de serie del certificado que es elegido por la CA. Si la CA usa números de serie aleatorios grandes, entonces el ataque no se aplica, incluso si se usa MD5 como función hash. Por otro lado, los CA que usan números de serie secuenciales o basados en el tiempo son predecibles.
Otra preocupación con las colisiones es sobre pruebas de seguridad . Se puede probar que algunos protocolos criptográficos son seguros bajo algunos supuestos específicos sobre las primitivas criptográficas utilizadas en el protocolo; por ejemplo, se puede probar que algunos protocolos que utilizan funciones hash son seguros siempre que se suponga que la función hash es resistente a la colisión, o alguna otra propiedad. Un ejemplo es HMAC . HMAC reutiliza una función de hash subyacente, y fue diseñada para acomodar las funciones de hash de Merkle– La persuasión de Damgård , especialmente MD5 y toda la familia SHA. Dicha función hash se basa en una "función de compresión" interna. Se ha comprobado que HMAC es seguro suponiendo que la función de compresión se comporta como una función pseudoaleatoria .
Sin embargo, si la función de compresión de MD5 es un PRF, entonces no es posible calcular las colisiones para MD5 con un costo inferior a 2 64 en promedio. Sabemos cómo producir colisiones MD5 por mucho menos que eso. Esto implica que la función de compresión MD5 es no un PRF. Así que esto anula la prueba de seguridad en HMAC / MD5.
¡Esto no significa que sepamos cómo romper HMAC / MD5 con colisiones! Es "justo" que cualquier garantía matemática de seguridad que tengamos se haya evaporado como un rocío matutino bajo el despiadado sol del mediodía. En ese sentido, las colisiones de MD5 no son una herramienta para ser aprovechadas por el atacante, pero aún así merecen atención.