PQC StatusEn una VPN, la parte expuesta a un futuro atacante cuántico es el intercambio de claves, no el cifrado de los datos. Para IPsec existen dos mecanismos publicados por el IETF que pueden utilizarse hoy: el RFC 9370, que permite a IKEv2 negociar intercambios de claves adicionales para que un KEM (mecanismo de encapsulación de claves) poscuántico funcione junto a un grupo clásico, y el RFC 8784, que incorpora una clave precompartida poscuántica a la derivación de claves de IKEv2. WireGuard no dispone de intercambio de claves poscuántico en el propio protocolo, por lo que su clave precompartida simétrica opcional de 32 bytes es la única palanca disponible dentro del protocolo.
Por qué el intercambio de claves va primero
Un túnel IPsec tiene dos capas. ESP (Encapsulating Security Payload) protege los datos con un algoritmo simétrico, normalmente AES-256-GCM. Los algoritmos simétricos y las funciones hash no se ven comprometidos por el algoritmo de Shor, y el algoritmo de Grover es la razón por la que se prefiere AES-256 para la protección a largo plazo. La capa IKE (Internet Key Exchange) es distinta: IKEv2, tal como se publica en el RFC 7296, deriva sus claves de un intercambio Diffie-Hellman, y tanto el Diffie-Hellman de curva elíptica como el Diffie-Hellman de cuerpo finito quedan rotos por el algoritmo de Shor en un ordenador cuántico suficientemente grande, sea cual sea el tamaño del grupo.
Esto importa ya por el riesgo de capturar ahora, descifrar después (HNDL): a un atacante que registre hoy el tráfico cifrado de un túnel le basta con que el intercambio de claves caiga más adelante para leerlo. Los túneles entre sedes que transportan datos con una vida útil de confidencialidad larga (historiales clínicos, expedientes jurídicos, diseños industriales, datos de pago) son el caso más claro. La autenticación es una cuestión aparte. La autenticación de pares en IKEv2 con certificados RSA o ECDSA solo tiene que resistir a un atacante presente en el momento del handshake, de modo que las firmas pueden migrarse después del intercambio de claves, pero también deben migrarse.
Los tres mecanismos disponibles hoy
| Mecanismo | Especificación | Qué cambia | Qué requiere |
|---|---|---|---|
| Intercambios de claves adicionales en IKEv2 | RFC 9370, con el intercambio IKE_INTERMEDIATE del RFC 9242 | Se negocia en banda un KEM poscuántico, además del grupo clásico | Soporte en ambos pares, un método de intercambio de claves registrado para el KEM, fragmentación IKEv2 |
| Incorporación de una clave precompartida poscuántica (PPK) | RFC 8784 | Se incorpora un secreto de alta entropía a la derivación de claves de IKEv2, de modo que un intercambio registrado no basta | Distribución fuera de banda, almacenamiento y rotación de una PPK por cada par de extremos |
| Clave precompartida de WireGuard | Documentación del protocolo WireGuard (opción PresharedKey) | Se incorpora una clave simétrica de 32 bytes a la clave de encadenamiento del handshake | Distribución fuera de banda por cada par de extremos, sin negociación en banda |
| Protección de la carga útil ESP | AES-256-GCM | Nada: ya está fuera del alcance de Shor | Preferir AES-256 para la protección a largo plazo |
RFC 9370: intercambios de claves adicionales en IKEv2
IKEv2 básico negocia exactamente un método de intercambio de claves, en el intercambio IKE_SA_INIT. El RFC 9370 añade hasta siete tipos de transformación de intercambio de claves adicionales (habitualmente denominados ADDKE1 a ADDKE7), que se negocian en la misma propuesta y se ejecutan después en uno o varios intercambios IKE_INTERMEDIATE, el tipo de intercambio definido en el RFC 9242. Los secretos compartidos resultantes se combinan en el material de claves de la IKE SA, de modo que mantener un grupo clásico como primer intercambio de claves y añadir un KEM como ADDKE1 produce un esquema híbrido: el atacante tiene que romper ambos. El modo híbrido es lo que recomiendan ANSSI y BSI, y es la opción prudente mientras las implementaciones poscuánticas sean jóvenes.
El KEM que conviene solicitar es ML-KEM, normalizado por NIST en FIPS 203 el 13 de agosto de 2024. ML-KEM-768 es el conjunto de parámetros intermedio habitual; CNSA 2.0 exige ML-KEM-1024. La lista de referencia de identificadores de métodos de intercambio de claves de IKEv2 es el registro IANA de parámetros IKEv2, y el trabajo para especificar ML-KEM en IKEv2 se desarrolla en el grupo de trabajo IPSECME del IETF, así que consulte el registro y la documentación de su implementación en lugar de fiarse de un número de transformación citado en un artículo.
Dos consecuencias operativas. Primero, las claves públicas y los textos cifrados de ML-KEM son mucho mayores que un punto de curva elíptica, por lo que conviene activar la fragmentación de mensajes IKEv2 (RFC 7383). Uno de los motivos por los que el RFC 9370 utiliza IKE_INTERMEDIATE es que esos intercambios pueden fragmentarse, a diferencia de IKE_SA_INIT. Segundo, la sintaxis de las propuestas varía entre implementaciones y versiones, y la palabra clave para un intercambio de claves adicional poscuántico no es portable. Verifíquela en la documentación de su versión exacta:
# Illustrative shape only, not a portable configuration line.
# Order: encryption - integrity/PRF - classical group - additional key exchange 1
# aes256gcm16 - prfsha384 - <classical group> - <ML-KEM as ADDKE1>
# The keyword for the additional key exchange depends on the implementation
# and its version. Take it from that version's documentation.Unas comprobaciones de solo lectura en una pasarela Linux, antes y después de un cambio, muestran lo que el kernel ha instalado realmente:
# List the IPsec security associations and the ESP algorithms in use
ip -s xfrm state
# Show the installed IPsec policies
ip xfrm policyPruebe primero en preproducción, con los pares que utiliza realmente, y mantenga una propuesta exclusivamente clásica como alternativa documentada hasta que todos los pares hayan migrado.
RFC 8784: incorporación de una clave precompartida poscuántica
El RFC 8784 sigue otro camino. El iniciador indica su soporte con una notificación USE_PPK, y una clave precompartida poscuántica, identificada mediante un PPK_ID, se incorpora a la derivación de claves de la IKE SA. Un atacante que registre el intercambio y rompa más adelante la parte Diffie-Hellman sigue sin poder derivar las claves de sesión sin la PPK. Resulta útil precisamente porque no necesita ningún algoritmo asimétrico nuevo: muchas pilas IKEv2 ya desplegadas pueden hacerlo.
Los límites son operativos más que criptográficos. La PPK debe tener una entropía real y generarse con una fuente aleatoria adecuada, no teclearla una persona. Debe distribuirse, almacenarse y rotarse fuera de banda, por cada par de extremos, lo cual es la parte difícil a escala. No hace poscuántica la autenticación de pares. Además, el RFC 8784 permite que la PPK sea obligatoria u opcional: si es opcional, un par que no envíe USE_PPK obtiene simplemente una SA clásica. Cuando ambos extremos lo admitan, configúrela como obligatoria y registre qué pares han negociado una PPK, para poder demostrar la cobertura en lugar de suponerla.
WireGuard hoy
El handshake de WireGuard se basa en Curve25519, por lo que el intercambio de claves es vulnerable a la computación cuántica del mismo modo que IKEv2 con un grupo clásico. Por diseño, el protocolo no tiene capa de negociación ni agilidad algorítmica, así que no hay ningún intercambio de claves poscuántico que activar. Lo que existe es la clave precompartida simétrica opcional, incorporada al handshake, que la documentación del protocolo WireGuard presenta como mitigación frente a un atacante que registre el tráfico ahora y ataque las claves públicas más adelante.
# Generate one 32 byte pre-shared key per peer pair
wg genpsk
# In a wg-quick configuration file, add it to the peer section
# [Peer]
# PublicKey = <peer public key>
# PresharedKey = <output of wg genpsk>
# AllowedIPs = 10.0.0.2/32Trate el resultado como un secreto con ciclo de vida: único por par, entregado por un canal de confianza, rotado y registrado en su inventario de claves. Algunos proyectos ejecutan un daemon externo que realiza por separado un intercambio de claves poscuántico y renueva periódicamente el valor de PresharedKey (Rosenpass es un ejemplo de código abierto de este patrón). Así WireGuard queda intacto, a cambio de un componente más que desplegar, supervisar y auditar. Si necesita negociar en banda un KEM normalizado, IPsec con el RFC 9370 es la vía que existe hoy.
Qué preguntar a los proveedores de VPN
| Pregunta | Por qué importa |
|---|---|
| ¿Qué métodos de intercambio de claves poscuánticos admite la implementación IKE, en qué versión de firmware y con qué identificadores IANA de método de intercambio de claves? | Convierte un argumento comercial en algo que puede probar y documentar |
| ¿Implementan el RFC 9370 con el RFC 9242, el RFC 8784 o ambos? | Un KEM híbrido en banda y la incorporación manual de una PPK resuelven el problema de forma distinta |
| ¿El intercambio de claves es híbrido y con qué conjunto de parámetros de ML-KEM? | El modo híbrido es la postura recomendada; CNSA 2.0 exige ML-KEM-1024 |
| ¿La implementación está validada conforme a FIPS 203 o utiliza un módulo validado? | Lo exigen algunos marcos de contratación y auditoría |
| ¿Está activada la fragmentación IKEv2 y cuál es el efecto medido sobre la tasa de renegociación de claves, la CPU y el tiempo de establecimiento del túnel? | Las cargas KEM más grandes modifican el tamaño de los paquetes IKE y la carga de la pasarela |
| ¿Qué ocurre cuando un par no admite el intercambio poscuántico, y puede registrarse o generar una alerta? | Necesita visibilidad sobre una vuelta silenciosa a una SA exclusivamente clásica |
| ¿Qué pruebas de interoperabilidad se han realizado con los pares concretos que utilizamos (pasarelas en la nube, equipos de socios, clientes de acceso remoto)? | La interoperabilidad de IKEv2 híbrido es donde se atascan los despliegues |
| ¿Cuál es la hoja de ruta para la autenticación de pares poscuántica (certificados ML-DSA)? | Primero el intercambio de claves, después las firmas, pero ambos son necesarios |
| ¿Lo recibirá el hardware actual o solo la próxima generación? | Los aceleradores criptográficos dimensionados para curvas elípticas pueden no ser capaces de ejecutar ML-KEM |
| ¿Qué evidencias escritas proporcionarán: notas de versión, informes de pruebas, configuración admitida? | Es lo que se incorpora a su inventario criptográfico |
Las fechas aplicables a los equipos de red
Las pasarelas VPN se mencionan explícitamente en un calendario. CNSA 2.0 de la NSA, aplicable a los National Security Systems de EE. UU., fija el uso exclusivo de su conjunto de algoritmos (entre ellos ML-KEM-1024) para finales de 2030 en la firma de software y firmware y en los equipos de red tradicionales, y para finales de 2033 en navegadores y servidores web, servicios en la nube, sistemas operativos y equipos de nicho. Los equipos de red están en el primer grupo.
En otros ámbitos, BSI TR-02102-1 (versión 2026-01, publicada el 23 de enero de 2026) recomienda un acuerdo de claves poscuántico híbrido y considera aceptable el acuerdo de claves clásico utilizado en solitario solo hasta finales de 2031, o hasta finales de 2030 para necesidades de protección muy elevadas; se trata de una guía técnica, no de una norma. ANSSI hace obligatoria la hibridación dentro de su ámbito regulado (cualificación de productos, Diffusion Restreinte, SAIV y SIIV) e indica que sus recomendaciones poscuánticas aún no son obligaciones reglamentarias fuera de él (FAQ PQC de ANSSI). La Hoja de ruta de implementación coordinada de la UE v1.1 (23 de junio de 2025) pide inventarios criptográficos y hojas de ruta nacionales para finales de 2026 y la migración de los casos de uso de alto riesgo para finales de 2030; es una orientación coordinada para los Estados miembros, no una norma vinculante para las empresas. El NCSC del Reino Unido (20 de marzo de 2025) prevé la fase de descubrimiento y un plan inicial para 2028, las migraciones de máxima prioridad para 2031 y la finalización para 2035. NIST IR 8547 sigue siendo un borrador público inicial: propone declarar obsoletos después de 2030 los algoritmos con una seguridad de 112 bits, como RSA-2048, y prohibir después de 2035 todos los algoritmos de clave pública vulnerables a la computación cuántica.
Nuestra lectura, ofrecida como interpretación y no como asesoramiento jurídico: un túnel entre sedes de larga duración que transporta datos regulados es el tipo de caso de uso de alto riesgo al que apuntan primero estos calendarios, lo que sitúa el parque VPN al principio de la cola incluso cuando el texto es una recomendación y no una obligación.
Siguiente paso
Empiece por el inventario, porque es lo que piden todos estos textos: enumere cada túnel, la versión de IKE, el grupo de intercambio de claves negociado, los algoritmos ESP, el método de autenticación y la vida útil de confidencialidad de los datos que transporta. Después elija un túnel de bajo riesgo entre dos pares que controle y pruebe una propuesta híbrida en preproducción, manteniendo una alternativa clásica.
PQC Status analiza TLS, no IKEv2, por lo que no le dirá qué negocia su pasarela en UDP 500 y 4500. Aun así, es la comprobación más rápida de todo lo que un parque VPN expone por HTTPS: portales web de los equipos, frontales SSL-VPN, interfaces de administración y de alta. Realice un análisis gratuito de esos nombres de host con PQC Status para ver si ya ofrecen un intercambio de claves híbrido ML-KEM y, después, envíe las preguntas anteriores al fabricante de cada pasarela.