Resumen

  • El RFC 1321 de abril de 1992 describió MD5 e incluyó una implementación de referencia en C, un programa de prueba y siete salidas esperadas. Un desarrollador podía comparar su código con resultados compartidos.
  • El RFC 6151, publicado en 2011, actualizó el juicio de seguridad: MD5 dejó de ser adecuado cuando se necesitaba resistencia a colisiones, como en las firmas digitales. Los resultados de prueba seguían fijando el cálculo original.

Una receta que también entregaba la cocina

La huella de un archivo suele aparecer como una hilera de caracteres hexadecimales, una respuesta con aspecto de contraseña que el programa ofrece sin conversación. El RFC 1321 explicaba cómo fabricar esa respuesta. Primero se añadían bits de relleno hasta una posición exacta; después, la longitud original del mensaje. Cuatro palabras de 32 bits servían de estado inicial y la entrada se procesaba en bloques de 512 bits. El orden de los bytes y el relleno eran parte de la receta. Una pequeña diferencia ahí bastaba para que dos ordenadores discutieran sobre el mismo mensaje.

Rivest puso herramientas de taller al lado de la descripción. El apéndice A contenía global.h, md5.h, md5c.c y mddriver.c. El último archivo podía calcular huellas de cadenas, archivos o la entrada estándar. Con la opción -x ejecutaba una serie de pruebas. El apéndice A.5 publicaba las respuestas para siete entradas, desde la cadena vacía y a hasta frases, alfabetos y una cadena larga de dígitos. Para abc, la salida era 900150983cd24fb0d6963f7d28e17f72. El examen llegaba con su solucionario: cada equipo podía averiguar enseguida si había interpretado la regla igual que el autor.

El código procedía de RSAREF, una herramienta criptográfica para Privacy-Enhanced Mail. Su inclusión acortaba el viaje entre una especificación escrita y una implementación que se podía ejecutar. Un programador tenía la explicación, un ejemplo en C y valores con los que comprobar el resultado. Otro podía adaptar ese ejemplo a su plataforma y detectar una confusión de representación antes de intercambiar huellas con nadie. El RFC describía el código como portable e incluso sugería una optimización para determinadas máquinas de orden de bytes bajo. La publicación invitaba a llevar la regla al ordenador propio.

MD5 nacía con una apuesta de seguridad. Era una evolución de MD4. El documento de 1992 consideraba que MD4 quizá había sido adoptado más deprisa de lo que permitía la revisión crítica disponible; MD5 sacrificaba algo de velocidad para buscar un margen mayor. Su aplicación prevista incluía firmas digitales: resumir un archivo grande antes de una operación con clave privada. El algoritmo se ponía en el dominio público para su examen y posible adopción como estándar, aunque el propio RFC tenía categoría Informational. La invitación llevaba una promesa de cálculo compartido y una hipótesis sobre lo difícil que sería encontrar dos mensajes con la misma huella.

La primera se podía poner a prueba con las siete respuestas del apéndice. La segunda pedía años de análisis criptográfico. Una implementación puede coincidir en cada vector publicado y seguir dependiendo, en su uso de seguridad, de una conjetura que los ataques futuros pondrán a prueba. No hay paradoja: hacer bien una cuenta y pedirle a esa cuenta que resista a un adversario decidido son tareas distintas. La hoja de respuestas revela fallos de implementación; el adversario examina la premisa de la pregunta.

En marzo de 2011 llegó el RFC 6151. Después de los ataques publicados contra MD5, actualizó las consideraciones de seguridad del RFC original y fue tajante con los usos que exigían resistencia a colisiones, incluidas las firmas digitales. También distinguió aplicaciones con otras exigencias, como HMAC-MD5 o la detección de errores accidentales, y recomendó evitar HMAC-MD5 en nuevos diseños de protocolo. Esa nueva valoración no alteró el digest de abc. Alteró el precio de confiar en que una huella igual probaba lo que una firma necesitaba probar.

Las dos publicaciones juntas muestran una cualidad poco habitual de un documento técnico bien equipado. RFC 1321 ofreció el algoritmo, un programa de referencia y observaciones reproducibles en una misma pieza. Esos recursos dieron a desarrolladores independientes una mesa de trabajo compartida. RFC 6151 volvió sobre la interpretación de seguridad cuando cambió la evidencia. La ejecución correcta conservó su definición; el uso aceptable se movió. El solucionario seguía al final del examen. La asignatura había cambiado.