Resumen

  • SIV conserva la autenticidad cuando se repite un nonce, pero deja visible si se repitieron también el texto claro y los datos asociados bajo la misma clave.
  • La resistencia al mal uso es una defensa de último recurso. La unicidad, el perfil de uso, el orden de AD y la retención del claro hasta validar siguen siendo controles independientes.

No hubo una catástrofe; sí hubo una observación

En varios modos AEAD, reutilizar la pareja clave–nonce con mensajes distintos puede derrumbar confidencialidad o integridad. SIV cambia ese desenlace mediante dos pasos. Primero, S2V procesa con CMAC una secuencia de datos asociados y el texto claro para obtener un vector sintético. Después, ese valor alimenta AES-CTR. La salida lleva el vector de 128 bits y el cifrado.

Cuando el nonce es único, el protocolo ofrece la seguridad ordinaria descrita en RFC 5297. Cuando se repite, un tercero no obtiene permiso para fabricar otro mensaje aceptable. Sin embargo, puede reconocer la igualdad si coinciden el claro y todo el contexto autenticado. Esa relación puede delatar que una orden no cambió, que reapareció el mismo derecho, que dos usuarios recibieron el mismo objeto o que un evento secreto volvió a ocurrir.

La palabra “resistente” identifica el límite del daño. No modifica la definición de nonce, que excluye la reutilización. RFC 8452, para otra construcción posterior, insiste en la misma disciplina: la resistencia proporciona la mejor protección posible cuando ocurre el error, no una política para provocar el error.

La decisión de modo precede al cifrado

SIV puede operar con nonce o de forma determinista. En el primer caso, el nonce es el último componente de los datos asociados, inmediatamente antes del claro. Otros componentes pueden fijar cuenta, tipo, versión, destinatario o propósito. Si el nonce es aleatorio, RFC 5297 recomienda al menos 128 bits y una fuente con 128 bits de entropía; también admite un contador o sello temporal bajo una regla de unicidad adecuada.

En el modo determinista no se incorpora nonce. El caso central es envolver datos impredecibles para el adversario, como una clave criptográfica. Que la API acepte ambos modos no significa que cualquier llamador pueda escogerlos. Un registro operativo debe conservar el perfil autorizado y la razón por la que el objeto era apto para el modo determinista.

Confundir los perfiles produce dos diagnósticos opuestos y erróneos. Un equipo puede tratar una salida determinista esperada como incidente de nonce repetido. Otro puede llamar “determinista” a una corriente de comandos predecibles para evitar gestionar estado. La salida no resuelve esa disputa; hace falta el recibo de intención y autorización.

Un vector no es una bolsa de bytes

RFC 5297 permite que AD sea un vector de cadenas de longitud variable. S2V incorpora cada componente en orden. Por eso, cambiar la posición de tenant y recipient, omitir version o combinar dos campos altera el enunciado autenticado.

La interfaz de RFC 5116 solo lleva un componente AD. Para invocar SIV a través de ella, el software debe serializar el vector. El formato de serialización es parte de la seguridad: longitudes, tipos y versión deben impedir que dos divisiones diferentes produzcan la misma cadena. Un tag válido demuestra identidad de bytes, no acuerdo semántico entre dos versiones del programa.

El máximo de 126 componentes asociados también debe aparecer en la validación previa. S2V admite 127 componentes y el texto claro ocupa uno. Si un adaptador agrupa o descarta campos para entrar en el límite, no está optimizando la misma petición; está protegiendo otra afirmación.

El candidato no es todavía el mensaje

Para descifrar, CTR produce un claro candidato. El receptor vuelve a ejecutar S2V con AD y ese candidato. Solo si el resultado coincide con el vector recibido puede devolver el claro; de lo contrario devuelve FAIL.

Esa secuencia crea una frontera de software. Un parser que empieza antes de la comparación, un logger que captura el candidato o un caché que lo conserva han concedido efectos a datos no autenticados. La primitiva puede pasar sus vectores de prueba y el producto seguir violando el modelo.

La evidencia debe registrar la cuarentena. candidate_created, authentication_checked, released y application_accepted son eventos distintos. El último añade validación de esquema, autorización y efecto; no puede deducirse del tag.

Presupuestos que no caben en una sola alarma

RFC 5297 recomienda ser prudente con el número de invocaciones distintas bajo una clave y cita 2^48 siguiendo el límite práctico de CMAC. Ese presupuesto no es el contador de nonces. Una clave puede consumir demasiadas invocaciones sin repetir nonce; también puede repetir pronto con poco volumen. Medir uno no demuestra el otro.

IANA registra los códigos 15, 16 y 17 para las variantes AES-SIV-CMAC. Los códigos coordinan nombres. No prueban selección efectiva, división correcta de la clave, perfil de modo, serialización AD, unicidad, cuarentena ni aceptación final.

El recibo completo enlaza algoritmo y build; generación de clave; modo; esquema y hashes de AD; fuente y veredicto del nonce; hash autorizado del objeto; vector sintético; comparación; liberación; clasificación del duplicado; exposición de igualdad; decisión de la aplicación; y presupuestos por clave. No contiene secretos.

Sources