Resumen

  • RFC 10032 es una publicación Informational del flujo IRTF, fruto del consenso de CFRG; no es un mandato del Standards Track de IETF. Sus seis asignaciones de IANA son nombres estables, no obligaciones de despliegue.
  • Los códigos separan AEGIS-128L, AEGIS-256 y cuatro formas paralelas X2/X4, pero no codifican la elección de etiqueta de 128 o 256 bits. Los modos paralelos son opcionales y requieren acuerdo sobre la variante exacta.
  • Un autotest de biblioteca acredita resultados para entradas fijas. No acredita la oferta y selección entre pares, el binario y la ruta de CPU ejecutados, la construcción de nonce y datos asociados ni la suite observada en tráfico real.
  • Un recibo de custodia debe enlazar documento y registro, perfil de protocolo, selección autenticada, código y etiqueta, ciclos de clave y nonce, serialización de datos asociados, ruta de ejecución, pruebas positivas y negativas, fallos, contadores, fallback y rollback.

El registro resuelve un nombre, no una sesión

IANA asigna 32 a AEAD_AEGIS128L, 33 a AEAD_AEGIS256, 34 y 35 a AEGIS-128X2/X4, y 36 y 37 a AEGIS-256X2/X4. Eso evita que especificaciones distintas reclamen el mismo identificador para algoritmos incompatibles. También permite que una interfaz, una configuración o un inventario hable de una variante sin ambigüedad nominal.

Pero un número registrado no contiene una transcripción de negociación. RFC 5116, que define la interfaz común y el registro AEAD, advierte que registrar un algoritmo no supone aprobarlo ni avalar su seguridad. La interfaz tampoco fija la política antirrepetición o el control de acceso. Esas decisiones recaen en el protocolo que llama a la primitiva y en su despliegue.

RFC 10032 aporta las definiciones, parámetros, recomendaciones operativas y vectores de prueba. No establece una única negociación para TLS, IPsec, QUIC, almacenamiento y canales privados. Cada perfil debe decidir si ofrece AEGIS, cómo representa la selección, qué longitud de etiqueta usa, cómo crea claves y nonces, qué bytes forman los datos asociados y qué ocurre al fallar la autenticación.

Por eso «la biblioteca soporta AEGIS» y «esta sesión usó AEGIS-128X2 con estos parámetros» son afirmaciones distintas. La primera describe capacidad. La segunda exige evidencia de acuerdo y ejecución.

La etiqueta editorial del RFC importa

RFC 10032 apareció en septiembre de 2026 en el flujo IRTF, con categoría Informational. Refleja consenso de CFRG, pero su propio estado aclara que no es un producto ni un estándar de IETF y que los resultados de investigación pueden no ser adecuados para despliegue.

No es una descalificación técnica. Es información sobre el tipo de autoridad y revisión. RFC 5743 describe la preparación en un grupo de investigación, la revisión del IRSG y la comprobación de conflictos por el IESG. RFC 7841 distingue ese camino de la revisión y aprobación amplia que recibe el Standards Track de IETF.

Conviene conservar cuatro hechos por separado: CFRG alcanzó consenso de investigación; el IRSG aprobó la publicación; el IESG revisó posibles conflictos con la normalización; e IANA reservó identificadores únicos. Ninguno registra la decisión de un protocolo, el valor por defecto de un producto ni la elección de dos extremos.

La página pública de IANA ofrecía el 20 de septiembre los seis códigos, mientras su columna de referencia aún mostraba el borrador 18 y la página indicaba una actualización del 7 de julio. No es prueba de invalidez. Es una instantánea fechada que muestra por qué publicación y estado registral deben capturarse por separado.

Dos pares pueden coincidir en 32 y discrepar en el cable

AEGIS-128L emplea clave y nonce de 128 bits; AEGIS-256 emplea ambos de 256 bits. Los dos permiten etiquetas de autenticación de 128 o 256 bits. Los seis nombres de IANA identifican familia y, cuando procede, grado de paralelismo, pero no incluyen la longitud de etiqueta.

Esa omisión tiene efecto técnico. RFC 10032 sitúa aproximadamente en 2^64 el trabajo de compromiso con una etiqueta de 128 bits y en 2^128 con una de 256 bits, para la propiedad descrita sobre claves o nonces distintos que verifican la misma tupla. Dos pares podrían declarar el código 32 y aun así esperar límites distintos entre texto cifrado y etiqueta. El nombre coincide; el perfil de cable no.

También hay que fijar el encuadre. La especificación permite mantener separados texto cifrado y etiqueta o concatenarlos, con la etiqueta inmediatamente después del texto cifrado. Un recibo que sólo diga «AEGIS-128L» no cuenta cuántos bits leyó el receptor ni cómo determinó la frontera.

Los datos asociados añaden otra dimensión. RFC 5116 menciona campos claros como direcciones, puertos, secuencias y versiones. RFC 10032 formula una propiedad de compromiso completo bajo la restricción de que el adversario no controle esos datos, y presenta construcciones adicionales cuando se necesita una afirmación más fuerte. La lista exacta de campos, orden, longitudes, versión y separación de dominios debe formar parte de la evidencia del protocolo.

X4 en un gráfico no es X4 en una conexión

AEGIS-128X y AEGIS-256X buscan aprovechar registros vectoriales amplios e instrucciones AES vectoriales. X2 y X4 expresan grados de paralelismo dos y cuatro. Su beneficio depende de la arquitectura y de la implementación.

La cautela normativa es clara: los protocolos deberían seleccionar una forma paralela sólo si todas las partes acuerdan esa variante concreta. AEGIS-128L y AEGIS-256 deben seguir siendo las opciones predeterminadas, y una implementación puede omitir X2 y X4.

Por tanto, un benchmark atractivo no crea compatibilidad. Un par remoto quizá sólo tenga la forma base. El binario desplegado puede haberse compilado sin la ruta X. Una migración de máquina virtual puede cambiar las instrucciones visibles. Un dispatcher puede elegir una ruta de reserva aunque la configuración continúe mostrando «AEGIS».

La prueba útil separa tres planos: qué ofreció y seleccionó el protocolo; qué capacidad exacta poseía cada extremo; y qué ruta ejecutó realmente el proceso. Un único indicador de soporte mezcla esos planos y oculta el lugar del fallo.

La unicidad del nonce necesita propietario

Para cifrado, RFC 10032 exige no repetir un nonce bajo una misma clave, incluso cuando cambia la longitud de la etiqueta. La reutilización revela de inmediato el XOR de los dos mensajes. El nonce puede ser público o predecible; puede proceder de un contador o de otro generador de periodo largo.

Con nonces aleatorios, la familia de 128 bits admite hasta 2^48 mensajes por clave con la probabilidad de colisión indicada, cercana a 2^-33. Para la familia de 256 bits, el texto habla de ausencia de un límite aleatorio práctico. Eso no elimina la regla de unicidad ni crea por sí solo una operación segura.

Un despliegue sigue necesitando dominio de unicidad, época de clave, persistencia ante reinicios, fuente aleatoria, reparto entre shards y detección de restauraciones o clones. Dos procesos restaurados desde la misma imagen pueden creerse propietarios del mismo siguiente valor. El tamaño del campo no resuelve ese conflicto.

La clave requiere una historia análoga: generación o derivación, contexto que la ata al protocolo, comienzo y cierre de época, identificador, separación entre usuarios y destrucción. Que la clave efímera pueda borrarse después de inicializar el estado interno es una propiedad a verificar en la implementación elegida, no una consecuencia automática de citar el RFC.

Los vectores verifican una primitiva, no una operación

RFC 10032 contiene vectores extensos para la ronda AES, algoritmos base, variantes X2/X4 y formas MAC. Detectan errores de orden de bytes, finalización, bloque parcial y etiqueta. Las comparaciones entre implementaciones independientes son una defensa valiosa.

Las pruebas negativas responden a otra pregunta. Hay que cambiar la etiqueta, un campo de datos asociados, el nonce y el grado paralelo y comprobar que todo falla. La especificación exige no revelar texto plano ni etiquetas calculadas tras un fallo, borrar el búfer descifrado y comparar etiquetas en tiempo constante. Una ruta acelerada que acierta los vectores positivos pero expone bytes antes de autenticar no mantiene el comportamiento requerido.

Incluso una batería perfecta termina en el laboratorio. No dice que un handshake real ofreció la suite probada, que ambos extremos autenticaron la selección, que se cargó la biblioteca esperada, que se activó la ruta acelerada ni que los contadores permanecieron dentro de la época de clave prevista.

Catorce piezas para un recibo de custodia

El siguiente recibo es un control editorial propuesto por Daniel Kade. No es un campo de RFC 10032 ni un certificado de conformidad de IETF, IRTF, CFRG o IANA.

Primero, debe registrar identidad del documento, flujo, categoría, instantánea de publicación y erratas e instantánea de IANA. Segundo, protocolo invocador, versión, perfil de suite y generación de configuración. Tercero, transcripción autenticada de oferta y selección, o evidencia equivalente del acuerdo entre pares.

Cuarto, código numérico y variante base, X2 o X4 exacta. Quinto, longitud de etiqueta y encuadre. Sexto, capacidades de los pares y conducta cuando falta una variante. Séptimo, origen, derivación, contexto, época, identificador y borrado de clave.

Octavo, construcción y persistencia del nonce, dominio de unicidad, reinicio y contador por clave. Noveno, campos y serialización canónica de datos asociados. Décimo, build de biblioteca, ruta de CPU/vector y fallback. Undécimo, vectores positivos, comparación cruzada y pruebas negativas.

Duodécimo, semántica de fallo, supresión de texto plano, evidencia de tiempo constante y alertas. Decimotercero, unión con sesiones o paquetes acotados y telemetría de uso. Decimocuarto, reglas de reserva, rechazo de downgrade, disparadores de rollback, salida del conjunto compatible y horizonte de conservación.

Ninguna pieza reemplaza las demás. El registro no prueba el handshake; el handshake no prueba la persistencia del contador; el vector no identifica el binario cargado; una captura sin época de clave y reglas de datos asociados no explica por qué aceptar sus bytes. El valor del recibo está en negarse a reducir todo eso a la palabra «soportado».

Fuentes