Resumen

  • RFC 10032 define AEGIS para cifrado autenticado, generación de flujo y códigos de autenticación. El cifrado exige un par (clave, nonce) único y retener el texto hasta verificarlo; el flujo descarta deliberadamente la etiqueta; solo la función MAC permite reutilizar el par con entradas distintas.
  • El código IANA, la coincidencia con un vector y el rendimiento no prueban el contrato de uso. La evidencia decisiva debe conservar el rol, la finalidad de la clave, el dominio del nonce, la codificación de datos asociados y la frontera que impide liberar bytes no autenticados.

La frase “usamos AEGIS” era cierta y, a la vez, insuficiente. Una biblioteca puede implementar perfectamente el núcleo y ofrecer tres puertas con consecuencias incompatibles. Si la telemetría conserva solo el nombre de familia, la investigación pierde la capacidad de responder qué prometían realmente los bytes.

RFC 10032 apareció en septiembre de 2026 como RFC informativo del flujo IRTF y refleja consenso del CFRG. No es una norma del Standards Track de IETF. Especifica AEGIS-128L, AEGIS-256 y las variantes vectoriales AEGIS-128X y AEGIS-256X, construidas con la función de ronda de AES. Los modos X aceleran el trabajo en procesadores apropiados; no convierten una elección de implementación en una autorización de protocolo.

IANA asignó los números 32 a 37 a seis variantes AEAD. El registro coordina nombres. No selecciona AEAD frente a flujo o MAC, no incluye la longitud de etiqueta, no define datos asociados y no demuestra qué binario procesó una sesión. El análisis ya publicado sobre RFC 10032 en BTW se ocupa de esa diferencia entre codepoint y negociación. Esta investigación toma otra frontera: una vez elegida la familia, ¿qué función se llamó y qué autoridad podía tener su salida?

El cifrado autenticado exige esperar

La función AEAD recibe mensaje, datos asociados, clave y nonce. Produce texto cifrado y etiqueta. El descifrado calcula la etiqueta esperada, la compara en tiempo constante y devuelve el texto únicamente si coincide.

El par clave-nonce no se puede repetir para cifrar. La restricción se mantiene aunque cambie la longitud de la etiqueta. Reutilizarlo revela la diferencia bit a bit de los mensajes y expone el estado interno en el fallo descrito. Un nonce puede ser público o predecible; lo que no puede ser es repetido bajo la misma clave.

El RFC cuantifica el uso aleatorio. Para AEGIS-128L y AEGIS-128X, hasta 2^48 mensajes bajo una clave dan una probabilidad de colisión aproximada de 2^-33. Para AEGIS-256 y AEGIS-256X, el análisis no establece un límite práctico. Esa ventaja reduce el riesgo de colisión accidental, pero no concede permiso para reutilizar intencionadamente el valor.

La segunda obligación es la custodia del texto provisional. Si la etiqueta falla, ni el texto ni la etiqueta incorrecta o calculada pueden salir; el búfer descifrado debe sobrescribirse. Una aplicación que empieza a analizar, registrar o ejecutar el texto antes del resultado ha roto la garantía aun cuando la llamada termine con error.

Por eso el recibo de una operación debe nombrar rol, variante, etiqueta, clave, asignación de nonce, codificación de datos asociados, resultado de verificación y cualquier efecto lateral. La etiqueta protege una tupla de bits. No gobierna un callback que ya envió parte de esos bits a otra autoridad.

El modo flujo elimina la etiqueta por diseño

Para producir un flujo, RFC 10032 cifra ceros sin datos asociados y descarta la etiqueta. La finalización puede omitirse. La salida es un flujo de clave, no un mensaje autenticado.

El servicio es legítimo cuando una construcción superior sabe lo que recibe. El error aparece cuando el nombre familiar “AEGIS” presta al flujo la reputación del AEAD. Un panel muestra “cifrado AEGIS”; una interfaz retorna un arreglo de bytes; otra capa asume que alguna etiqueta será comprobada. No existe: fue descartada por definición.

La función de flujo necesita una finalidad de clave propia, un espacio de nonce propio y un tipo de salida que declare “no autenticado”. La construcción consumidora debe registrar qué mecanismo independiente aporta integridad, en qué orden opera y cuándo puede liberarse el texto. Sin ello, una salida correcta puede sostener una afirmación falsa.

El MAC contiene la única excepción

La función MAC absorbe datos y devuelve una etiqueta de 128 o 256 bits. RFC 10032 afirma que es la única función donde el mismo (clave, nonce) puede usarse con entradas diferentes.

La excepción pertenece a la función, no a la marca AEGIS. Una política global de nonce puede trasladarla al cifrado. El núcleo criptográfico no conoce ese error de autoridad y seguirá produciendo bytes.

La etiqueta MAC tampoco es un objeto universal. No debe usarse como hash si la clave puede conocerse, porque se pueden construir entradas con colisiones de estado. No debe alimentar una derivación de clave, pues no se garantiza una distribución uniforme. Que tenga 128 o 256 bits no la transforma en digest ni en secreto nuevo.

La separación debe imponerse mediante identificadores y tipos: claves ligadas a AEAD, STREAM o MAC; etiquetas de derivación diferentes; asignadores de nonce independientes; rechazo automático de una clave en otra puerta. Una nota de documentación no sustituye esos límites.

La etiqueta y los datos asociados siguen siendo decisiones locales

RFC 10032 admite etiquetas de 128 y 256 bits. En el juego de compromiso descrito, la primera ofrece aproximadamente 64 bits y la segunda unos 128. El identificador AEAD no revela cuál se usó.

La propiedad también depende de quién controla los datos asociados. AEGIS es plenamente comprometido en el caso restringido donde el adversario no los controla. Si puede modificarlos, el análisis citado permite hallar con eficiencia varias claves que verifican el mismo texto. Un protocolo que necesite compromiso pleno puede resumir los datos asociados con una función resistente a colisiones y preimágenes o vincular una codificación inequívoca mediante el campo info de una KDF, respetando las condiciones del RFC.

Nada de eso nace automáticamente del algoritmo. El protocolo decide campos, serialización y amenazas. El primitivo autentica los bits entregados, no el significado empresarial que una aplicación les atribuye.

Los vectores no prueban la ruta de custodia

Los vectores extensos de RFC 10032 demuestran correspondencia matemática para casos fijos. La interoperabilidad entre implementaciones amplía esa prueba. Todavía falta confirmar qué función se cargó en producción y qué ocurrió en el fallo.

Las pruebas negativas deben intentar confundir roles: usar una clave en otra interfaz; repetir un nonce de cifrado con otra etiqueta; comprobar que la excepción MAC no altera el asignador AEAD; exigir que el flujo se marque como no autenticado; corromper texto, tag y AD y observar que no sale ni un byte; enviar tags MAC a APIs de hash o KDF y esperar rechazo; verificar binario y ruta CPU; separar contadores de los tres servicios.

La seguridad frente a tiempo, potencia y fallos depende de la función AESRound real y del modelo de amenaza. El RFC observa que una clave efímera puede borrarse tras la inicialización porque las operaciones posteriores usan el estado. Solo una prueba del código ejecutado muestra que el borrado ocurrió.

Un recibo operativo debe unir propósito, rol, variante, paralelismo, longitud de etiqueta, identidad y finalidad de clave, asignación de nonce, esquema AD, versión y ruta de biblioteca, verificación, borrado, frontera de salida, contadores y decisión de aplicación.

La especificación mínima de Lu Heng permite que un primitivo común coordine sin gobernar todo lo que lo rodea. El registro nombra; la biblioteca calcula; el protocolo organiza; la aplicación autoriza la consecuencia. La disciplina de capas de realidad impide que un RFC o una etiqueta adquiera autoridad sobre identidad, permiso o resultado.

El aprendizaje central de RFC 10032 no es solo que AEGIS hace tres trabajos. Es que la reutilización de maquinaria no unifica los deberes. El nombre permaneció igual; la institución debe conservar separados los recibos.

Fuentes