Resumen

  • RFC 3394 convertía n bloques de datos en n+1 bloques cifrados mediante seis pasadas que mezclaban un registro de integridad; el bloque adicional era estado transformado, no relleno posterior.
  • La operación inversa sólo podía devolver datos si el registro recuperado coincidía con el valor inicial esperado; ese recibo no demostraba identidad, autorización, frescura, custodia de la KEK ni utilidad posterior.

La longitud contaba la historia antes de abrir el paquete. Entraban n bloques de 64 bits y salían n+1. El bloque sobrante no estaba fuera del cálculo. Había recorrido todas las estaciones y terminaba vigilando la salida.

RFC 3394 se publicó en septiembre de 2002 como documento Informational. Llevó la especificación AES Key Wrap de NIST al registro de Internet y declaró su procedencia: gran parte del texto venía de NIST y las afirmaciones de seguridad correspondían al gobierno estadounidense. La aportación documental fue una transformación reproducible y una frontera de aceptación explícita.

Los “datos de clave” podían incluir una clave, varias o información asociada. La KEK podía tener 128, 192 o 256 bits. La entrada se dividía en n bloques de 64 bits, con un mínimo de dos, y la salida añadía exactamente uno.

Los bloques ocupaban R[1] a R[n]; el registro A empezaba en un valor inicial. Seis pasadas por todos los registros producían 6n llamadas AES. En cada paso se cifraba A | R[i]; la mitad baja sustituía a R[i], mientras la alta, combinada con el contador t, actualizaba A.

El A final se publicaba como C[0]. No era padding añadido al final, sino estado tocado por cada bloque y posición. Cambiar un bloque, usar otra KEK, alterar el orden o esperar otro IV debía impedir que el recorrido inverso recuperase el comienzo correcto.

Unwrap deshacía operaciones y contadores, pero sus salidas seguían siendo candidatas. Sólo una comparación válida de A permitía liberar los registros. Si el valor no era apropiado, la implementación debía devolver error y ningún dato. La seguridad dependía tanto del cálculo como de obedecer esa prohibición.

El IV predeterminado repetía A6 durante 64 bits. El RFC asociaba la recuperación de ese patrón con una probabilidad 2^-64 de corrupción residual, dentro de sus supuestos. No era una tasa medida, una firma humana ni un certificado del sistema de custodia.

El éxito decía que ciphertext, KEK, variante e IV eran coherentes. No decía quién envolvió, si tenía permiso, si el objeto era nuevo o repetido, si la KEK había sido copiada ni si la clave resultante servía para el siguiente algoritmo. Una KEK comprometida puede crear envolturas que pasan perfectamente el control.

Por la misma razón, un vector de prueba sólo comprueba bytes. No demuestra resistencia a canales laterales, errores uniformes o manejo seguro en producción. RFC 3394 advertía expresamente que perder la KEK podía revelar todos los datos protegidos por ella.

El límite original requería al menos dos bloques y longitudes múltiples de 64 bits. El texto dejó espacio para valores iniciales alternativos cuando la aplicación necesitara otra extensión de integridad o longitud. Esa interfaz se convirtió en una vía de evolución.

RFC 5649 la utilizó para Key Wrap with Padding. Su AIV combina una constante de 32 bits con un indicador de longitud de 32 bits; al desenvolver se validan constante, longitud posible y ceros de relleno, y existe un caso especial para un solo bloque. Cambiar el dominio exigió cambiar el recibo.

RFC 3565 añadió identificadores CMS; JOSE y COSE adoptaron después familias AES-KW. Esos nombres eligen transformación y tamaño dentro de otros protocolos, pero no convierten A en identidad ni vuelven intercambiables KW y KWP.

Las erratas verificadas corrigen redacción e índices; las retenidas aclaran notación y un enlace histórico. Son esenciales para leer fielmente el algoritmo, sin cambiar sus seis vueltas ni la regla de no entregar datos ante fallo.

La especificación inicial mínima de Lu Heng ayuda a ver la proporción: se fijaron bloques, registros, contador, rondas, IV y error, mientras custodia y autorización quedaron donde residía su autoridad. La primacía del código en funcionamiento exige después evidencia de que la puerta existe realmente en software.

El registro adicional no certificaba el mundo. Separaba bytes candidatos de una clave liberada. Su éxito demostraba la forma interna del paquete; no quién merecía abrirlo ni qué ocurría después.

Fuentes