La mayoría de la gente se encuentra la palabra nonce en un perfil de VPN y supone que es otro secreto compartido que copiar entre pares. No lo es. Un nonce es un valor que nunca debe repetirse bajo la misma clave, y en la mayoría del cifrado basado en nonce viaja en claro. La confusión resulta inofensiva hasta que alguien lo edita a mano, y ahí empieza la avería real.

De dónde viene realmente el nonce

El cifrado autenticado necesita un nonce distinto para cada mensaje cifrado bajo una clave. Los protocolos satisfacen ese requisito de formas distintas: un contador que crece de forma monótona, una sal combinada con un identificador de paquete o un valor aleatorio suficientemente largo. IKEv2 intercambia nonces durante el intercambio inicial, y son entradas públicas para la derivación de claves, no secretos.

La unicidad puede ser estructural o probabilística. Un contador no puede repetirse hasta que da la vuelta, y por eso el protocolo define un punto de renovación de clave mucho antes. Un valor aleatorio depende de suficientes bits como para que una colisión sea inverosímil dentro del límite de mensajes, que es un argumento distinto con un modo de fallo distinto. La documentación del protocolo indica qué método se aplica, y ambos son seguros solo mientras se respete el límite declarado.

DesignWhere uniqueness comes fromExhaustion is handled by
AES-GCM recordsAn IV, typically a counterRekey before the counter wraps
ChaCha20-Poly1305A 96-bit nonce from a counter or generatorA message limit per key
WireGuardA per-key 64-bit counterRekey at a message cap
OpenVPN AEADPacket identifier plus implicit key materialRekey on the packet-id limit
IKEv2Fresh nonces per exchangeA new security association

Lo que realmente cuesta la reutilización

Reutilizar un nonce bajo una clave no es una cuestión menor de eficiencia. Con GCM, dos mensajes que comparten un IV permiten a un observador recuperar la clave de autenticación y calcular el OR exclusivo de los dos textos en claro. Las construcciones basadas en flujo reutilizan el flujo de clave de la misma manera, lo que convierte el texto cifrado en un rompecabezas en lugar de un secreto.

Por eso las implementaciones renuevan la clave antes de que un contador dé la vuelta, y por eso se detienen en lugar de continuar cuando su estado es incierto. Un reinicio que restablece un contador mientras el par aún conserva la clave antigua, o una máquina virtual restaurada desde una instantánea tomada a mitad de sesión, es exactamente la situación que los límites existen para evitar. No hace falta ningún atacante; las operaciones ordinarias bastan.

Por qué la edición manual es la solución equivocada

Los contadores, las sales y los identificadores de paquete son máquinas de estado compartidas por ambos extremos. Cambiar un lado desincroniza el otro, y el túnel falla de maneras que parecen un problema de enrutamiento. La palanca admitida es un intercambio de claves nuevo, que restablece el estado en ambos extremos a la vez.

Las contraseñas y los nonces también desempeñan papeles distintos. Una contraseña es una entrada secreta para la derivación de claves; un nonce es una entrada pública por mensaje. Un campo de perfil etiquetado como nonce que pide un secreto largo suele ser una clave estática o un secreto precompartido con otro nombre, así que lea la documentación de ese campo en lugar de suponer.

Cuando un aviso trata del manejo de nonces, la reparación es la versión corregida del mantenedor, no otro cifrado ni una clave más corta. Cambiar el cifrado para evitar la palabra nonce traslada el problema en lugar de resolverlo.

Leer un aviso sin adivinar

Una línea de registro sobre contadores o nonces suele describir estado perdido, no un ataque. Compruebe si un par se reinició, si una máquina virtual clonada reutilizó la misma identidad y si ambos extremos coinciden en la configuración de renovación de clave. Después establezca una sesión nueva y observe si el mensaje vuelve.

Mantenga el diagnóstico separado de los fallos no relacionados. Una página que no carga, o una solicitud de credenciales que se repite en bucle, no es evidencia de reutilización de nonce, y tratarla como tal le lleva a la capa criptográfica cuando el problema está por encima.

Para el uso ordinario, la regla segura es breve: deje que la implementación gestione el nonce, mantenga ambos extremos en versiones admitidas y trate cualquier reinicio de estado como un motivo para renovar la clave en lugar de editar un valor. Si un campo de perfil no aparece en la documentación del proveedor, no invente un valor para él. Arreglar el túnel empieza por saber qué capa está mirando.

Artículos relacionados