Resumen

  • RFC 2104 envolvió un hash iterativo existente en dos pasadas con clave y dos rellenos fijos, sin exigir cambios en la función de compresión.
  • El diseño permitía sustituir el hash y truncar el resultado, por lo que algoritmo, clave, bytes exactos y longitud de etiqueta formaban parte del contexto verificable.
  • Una coincidencia no identifica por sí sola a un emisor único ni demuestra autorización, frescura, canonicalización, confidencialidad, entrega o corrección operacional.

La pieza decisiva de RFC 2104 no fue un nuevo algoritmo de cifrado. Fue una manera de aprovechar software que ya existía sin tratar como segura cualquier concatenación improvisada de secreto y mensaje. En 1997, las implementaciones de MD5 y SHA-1 eran rápidas y conocidas. Hacía falta una composición con clave que pudiera analizarse, probarse y llevarse de un protocolo a otro.

HMAC resolvió ese problema técnico con un contrato deliberadamente pequeño. Su valor histórico reside tanto en lo que fijó como en lo que dejó fuera.

Una separación interior y otra exterior

El RFC 2104 llama H a la función hash, B al tamaño de bloque de entrada y L a la longitud de salida. Si K supera B, primero se reduce con H; si es menor, se completa con ceros. Después se aplican dos cadenas distintas de B bytes: ipad, formada por 0x36, y opad, formada por 0x5c.

El resultado es H((K xor opad) || H((K xor ipad) || text)). La primera pasada introduce el mensaje detrás de una derivación interior de la clave. La segunda vuelve a envolver ese resumen con una derivación exterior. El código del hash puede permanecer intacto.

Así se conservaban implementaciones y rendimiento, se simplificaba el tratamiento de claves y se abría la puerta a reemplazar H. Pero la fórmula no decía qué significaba text, quién podía solicitar una operación ni qué efecto debía seguir a una validación.

Los estados precalculados conservan la autoridad del secreto

La especificación permite guardar los estados intermedios después de procesar los bloques interior y exterior. En mensajes cortos, esa optimización evita repetir trabajo y no altera la interoperabilidad.

RFC 2104 advierte que esos estados deben protegerse igual que las claves. El detalle separa una optimización responsable de una falsa sensación de custodia. Un valor derivado reutilizable puede permitir el mismo trabajo operativo que el secreto original. Cambiarle el formato no lo convierte en información pública.

Tampoco basta la fórmula para conseguir claves aleatorias, intercambio seguro, rotación o secreto. El documento los considera ingredientes esenciales. HMAC normalizó el cálculo; la calidad de la clave y su ciclo de vida seguían dependiendo del sistema que lo usaba.

La etiqueta verifica bytes, no intenciones

Una aplicación puede truncar la salida y transmitir sus t bits de la izquierda. Esa longitud cambia la resistencia a una adivinación y debe quedar fijada en el protocolo. Por eso un registro que diga solamente «HMAC válido» omite la mitad de la evidencia: qué algoritmo, qué clave y época, qué representación y cuántos bits se compararon.

La representación exacta es una frontera propia. HMAC no sabe que dos serializaciones JSON o dos secuencias Unicode deberían expresar lo mismo. Si los extremos ordenan campos de forma distinta, las etiquetas divergen. Si ambos autentican de forma consistente un conjunto equivocado de campos, la etiqueta coincide y el error semántico permanece. La canonicalización se diseña antes de calcular el MAC.

La simetría también limita la atribución. Cualquier poseedor legítimo de la clave compartida puede crear una etiqueta válida. La verificación no distingue a una persona, servicio o equipo concreto dentro de ese grupo. HMAC no es una firma digital ni crea no repudio.

Los casos de prueba convirtieron la descripción en práctica común

El RFC 2202, publicado meses después, ofreció vectores HMAC-MD5 y HMAC-SHA-1. Claves, mensajes y salidas conocidas permitieron a implementaciones independientes comprobar que coincidían en el límite de bytes. Esa clase de evidencia hizo operativa la especificación.

Un vector superado no certifica toda una biblioteca. No recorre todas las longitudes, errores, carreras, comparaciones con filtraciones temporales, selección de claves ni estados antirreplay. Prueba una relación conocida entre entrada y salida; no la seguridad total del despliegue.

La sustitución estaba prevista, pero había que ejecutarla

RFC 2104 mencionó MD5 y SHA-1 como ejemplos de su época, pero dejó H genérico. Una década más tarde, RFC 4868 definió HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512 para IPsec. RFC 6151 actualizó el análisis de MD5 y desaconsejó HMAC-MD5 en nuevos diseños.

La abstracción sobrevivió al cambio de algoritmos. Eso no convirtió la migración en automática: hubo que asignar identificadores, negociar capacidades, actualizar implementaciones, políticas, pruebas y claves. Una interfaz estable reduce el acoplamiento; no elimina las decisiones ni los incentivos que perpetúan opciones antiguas.

La posterior normalización de HMAC en FIPS 198-1 muestra el alcance institucional de la composición. No concede vigencia perpetua a cada hash con el que se estrenó.

La confianza empieza donde termina la comparación

Un mensaje antiguo y su etiqueta antigua pueden volver a verificar. Para hablar de frescura hacen falta nonce, contador, ventana temporal u otro estado. Para hablar de autorización hace falta una regla que vincule el contexto autenticado con una acción. Para confidencialidad, cifrado. Para entrega o efecto persistente, recibos posteriores. Para corrección, revisión y operación segura.

RFC 2104 dio a Internet un mecanismo común, estricto y delgado. Dos pasadas de hash hicieron reutilizable el MAC. La decisión de confianza siguió siendo una construcción del sistema entero.

Fuentes