Resumen

  • RFC 9771 distribuye los adjetivos habituales de AEAD en cuatro familias; confundirlas puede convertir una afirmación verdadera sobre un algoritmo en un mensaje engañoso en el límite del sistema.
  • Una decisión defendible requiere un recibo de propiedad que conecte la noción formal, la construcción y versión, la conducta de la API, las pruebas negativas, el ciclo de claves y la integración del protocolo.

El adjetivo nunca fue la garantía

“Cifrado autenticado” suena a decisión de seguridad terminada. En realidad designa una primitiva cuya protección depende de un contrato entre algoritmo, disciplina de claves y nonces, datos asociados, interfaz y estado de protocolo. Publicado en mayo de 2025 por el Crypto Forum Research Group de la IRTF, RFC 9771 importa porque se niega a reducir ese contrato a una sola marca de calidad.

Es un documento informativo, no un estándar de Internet ni una certificación de despliegue. Su fuerza es taxonómica: separa la seguridad convencional de propiedades que resisten capacidades adversarias adicionales, y ambas de las propiedades de implementación y de las funciones que cambian la interfaz. Así, comprador, revisor y operador pueden reconocer qué clase de frase están oyendo antes de decidir qué prueba exige.

La interfaz convencional de RFC 5116 recibe clave, nonce, datos asociados y texto plano; el descifrado devuelve texto o fallo. Ya contiene una obligación operacional: cada invocación bajo una clave exige un nonce único. Una ficha que diga “AES-GCM” no aclara quién garantiza la unicidad, si resiste la restauración de una instantánea, cómo comparten el espacio los emisores concurrentes ni si acelerador y ruta de reserva usan el mismo estado.

RFC 9771 amplía el vocabulario sin eliminar esas preguntas. No es un menú en el que más adjetivos produzcan automáticamente más seguridad, sino un mapa de obligaciones de prueba distintas.

Cuatro familias, cuatro expedientes

Familia Qué cambia Evidencia necesaria
Seguridad convencional Confidencialidad e integridad base Construcción, parámetros, noción formal, límites concretos, vectores y topes de uso
Propiedad adicional de seguridad El adversario gana repetición de nonce, multiusuario, filtración o texto anticipado Componentes de confidencialidad e integridad, noción, diferencias y tests de abuso
Propiedad de implementación Cómo se realiza el cómputo Ruta medida, memoria y pasadas, frontera de verificación, paridad entre hardware y reserva
Función adicional Interfaz nueva, como actualización o expansión elegible Contrato de API, noción revisada, transiciones de estado, compatibilidad y fallos

La división expone un error frecuente. “Una pasada”, “paralelizable” y “procesable en flujo” describen una forma de computar; no prueban por sí solos confidencialidad ni integridad. RFC 9771 advierte que una construcción en flujo puede requerir seguridad por bloques e integridad cuando libera texto plano no verificado. Un benchmark de rendimiento no puede ser el recibo de seguridad de una API de streaming.

También ocurre el error inverso. Un resultado formal sobre la construcción no demuestra que la envoltura lo conserve. Si el descifrador entrega bytes antes de verificar la etiqueta, la aplicación entra en el modelo RUP, de liberación de texto no verificado. La confidencialidad convencional ya es imposible y cambian los objetivos pertinentes. Dos API con la misma primitiva —una con búfer y otra incremental— pueden sostener afirmaciones distintas.

Las funciones adicionales hacen la frontera aún más visible. RFC 9771 coloca el cifrado autenticado incremental y el robusto en un apéndice porque exceden la interfaz convencional. En el segundo, quien llama elige cuánto crece el texto cifrado para obtener la mayor integridad posible con esa expansión. Aquí “robusto” no significa “robustez de clave”, término usado a veces para compromiso de clave. Un acta que guarde solo la palabra ya perdió la distinción útil.

Los casi sinónimos esconden supuestos

Resiliencia y resistencia al mal uso de nonces parecen intercambiables; RFC 9771 dice que no. La resiliencia protege mensajes con nonces frescos aunque un adversario provoque repeticiones en otros puntos. La resistencia protege además mensajes que sí reutilizan nonce, salvo la filtración inevitable cuando se repite el mismo texto con el mismo nonce. La resistencia implica resiliencia, no al revés.

El plan de pruebas cambia. Una afirmación de resiliencia debe demostrar que el incidente no contamina tráfico fresco; una de resistencia también debe caracterizar el tráfico afectado. AES-GCM-SIV en RFC 8452 es una construcción estandarizada resistente al mal uso. Esa propiedad no se transfiere a GCM ordinario ni prueba el manejo de claves, límites o errores de la integración.

El compromiso presenta otra trampa. El compromiso de clave pregunta si un cifrado puede ser válido bajo claves distintas. El compromiso completo incluye nonce, datos asociados y texto plano. El completo implica el de clave, no al revés. Importa cuando una aplicación usa el éxito del descifrado para descubrir inquilino, cuenta o contexto. La investigación sobre descubrimiento de contexto muestra que la ambigüedad entre contextos válidos es real. Aun así, el recibo debe nombrar construcción, codificación del contexto, longitud de etiqueta y noción formal: una palabra no vincula lo que el sistema omitió codificar.

Del enunciado al recibo de propiedad

El recibo es un objeto de evidencia compacto y versionado, legible por compras, ingeniería de seguridad, operaciones y respuesta a incidentes. Empieza con la propiedad exacta y su familia RFC 9771. “Confidencialidad e integridad resistentes al mal uso de nonce” es una afirmación; “nonces más seguros” es publicidad. Si confidencialidad e integridad usan nociones diferentes, ambas se consignan. Una noción alternativa requiere prueba de equivalencia o una declaración de no equivalencia.

Después se congela el objeto de la evidencia: algoritmo y construcción, parámetros, longitud de etiqueta, proveedor o biblioteca, versión y build, ruta de CPU o acelerador y alternativa software. Una prueba del diseño y un test del binario responden a preguntas diferentes; hacen falta las dos.

La sección de interfaz registra entradas, momento de liberación, frontera de verificación, orden de fragmentos, cancelación y semántica de errores. Asigna quién construye nonces y datos asociados. Que un fallo no emita nada, entregue un búfer, libere parte del texto o llegue después de que el llamador actuó determina el modelo real.

Las pruebas negativas deben salir de la propiedad: nonce repetido, clave errónea, datos asociados alterados, cifrado de otro contexto, etiqueta truncada o falsificada, fragmentos reordenados, salida temprana, rollback, restauración, agotamiento del contador, transición de fase y discrepancia entre software y offload. Un test observa conducta, no sustituye la prueba formal; la prueba formal tampoco demuestra que la API cumplió sus premisas.

El ciclo de claves cubre generación y derivación, identidad, alcance de nonce y secuencia, concurrencia, topes, rotación, destrucción, copias y restauración, y agregación multiusuario. RFC 8645 describe mecanismos de renovación, pero el despliegue debe mostrar qué disparador usa y cómo solapa estados. Cambiar proveedor, acelerador, asignador de nonce, persistencia o política de rotación debe caducar el recibo.

Por último, la integración de protocolo aporta la evidencia entre primitiva y red. TLS 1.3 construye nonces de registro desde secuencias; QUIC añade número de paquete y fase de clave. Reintentos, anti-replay, recuperación, migración, encuadre, vinculación de contexto, interoperabilidad y terminación por hardware deben comprobarse por separado.

La pregunta que ya puede hacer el comprador

RFC 9771 permite pedir: “Para cada propiedad AEAD no convencional que afirme, entregue la noción exacta, la implementación y versión a las que se aplica, la conducta de API que preserva sus premisas, los tests negativos de frontera, los controles del ciclo de claves y las rutas de protocolo cubiertas”.

Que un proveedor responda “no soportado”, “solo en esta ruta” o “no probado bajo este fallo” es valioso: crea una frontera que puede valorarse, vigilarse y revisarse. Lo peligroso es un nombre sin dueño ni caducidad, porque convierte un resultado condicional en memoria institucional permanente.

Fuentes