PQC StatusRecolectar ahora, descifrar después (HNDL, por sus siglas en inglés) es un ataque paciente: capturar hoy tráfico cifrado, almacenarlo y descifrarlo años más tarde, cuando el acuerdo de claves que lo protegía ya no resista. Hoy no requiere ningún ordenador cuántico, solo capacidad de captura y espacio en disco. Por tanto, la pregunta útil para un equipo de seguridad no es cuándo existirá un ordenador cuántico criptográficamente relevante, sino durante cuánto tiempo debe permanecer confidencial cada flujo de datos y qué sistemas transportan los flujos con la vida útil más larga.
El modelo de amenaza, con precisión
Conviene separar al adversario en dos capacidades distanciadas en el tiempo.
- Hoy: recolección. Captura pasiva en un punto de derivación de red, en un proveedor de tránsito aguas arriba, en un punto de interconexión, en un balanceador de carga o un equipo intermedio comprometido, o el robo de un archivo de sesiones ya grabadas. El texto cifrado se almacena, no se lee.
- Más adelante: cómputo. Recuperación de una clave privada a partir de una clave pública. El algoritmo de Shor, en un ordenador cuántico suficientemente grande, rompe RSA, ECDH, Diffie-Hellman sobre cuerpos finitos, ECDSA, EdDSA y DSA, sea cual sea el tamaño de clave. Pasar de RSA-2048 a RSA-4096, o de una curva elíptica a otra mayor, no cambia nada.
La criptografía simétrica se comporta de otra manera. AES, SHA-2 y SHA-3 no quedan rotos por Shor. El algoritmo de Grover ofrece una ventaja menor, cuadrática, frente a las claves simétricas, y esa es la razón por la que se prefiere AES-256 cuando los datos deben permanecer confidenciales durante mucho tiempo. Una sesión grabada no está en riesgo porque AES-GCM protegiera la carga útil. Está en riesgo por la forma en que se acordó la clave AES.
El secreto hacia adelante no resuelve esto
TLS 1.3 utiliza siempre un acuerdo de claves efímero, en la práctica ECDH sobre X25519 o una curva del NIST. El secreto hacia adelante (forward secrecy) significa que robar mañana la clave privada de larga duración del servidor no revela las sesiones de ayer, porque el secreto de sesión procede de componentes efímeros. Pero esos componentes públicos efímeros viajan en claro dentro del handshake. Un handshake grabado contiene, por tanto, todo lo necesario para reconstruir el secreto de sesión, para cualquiera capaz de resolver esa única instancia del acuerdo de claves. El secreto hacia adelante protege contra el robo de claves. No protege contra un criptoanálisis posterior del propio acuerdo de claves. Esa brecha es todo el problema HNDL.
Por qué el intercambio de claves migra primero y las firmas después
Una firma se verifica en el momento de la conexión. Si un algoritmo de firma pasa a ser falsificable dentro de diez años, eso no permite a nadie leer una sesión grabada hoy: las claves de sesión nunca se derivaron del certificado. Lo que permite una firma rota es la suplantación en el futuro y artefactos falsificados que siguen siendo de confianza durante mucho tiempo.
De ahí el orden que siguen todas las hojas de ruta oficiales. Primero llega el acuerdo de claves poscuántico híbrido, basado en ML-KEM, el mecanismo de encapsulación de claves (KEM) normalizado como NIST FIPS 203 el 13 de agosto de 2024 (FIPS 203). Después vienen las firmas poscuánticas como ML-DSA (FIPS 204), para las cadenas de certificados. Los grupos TLS híbridos X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024 figuran en el registro de parámetros TLS de IANA, y el RFC 10024 (agosto de 2026) especifica el acuerdo de claves híbrido poscuántico y tradicional (PQ/T) para TLS 1.3. Las versiones actuales de Chrome, Edge y Firefox ofrecen X25519MLKEM768 por defecto, de modo que para muchos endpoints públicos se trata de un cambio de configuración y no de un proyecto.
Después no significa nunca, y dos clases de firma merecen atención temprana de todos modos:
- Firmas cuya verificación debe seguir siendo fiable tras un largo plazo: firma de firmware y de actualizaciones de software, raíces de confianza del arranque seguro, firmas de archivos y documentos, sellado de tiempo.
- Certificados y credenciales de larga validez, cuya reemisión es costosa o físicamente complicada: productos embebidos, equipos industriales, tarjetas inteligentes.
La NSA CNSA 2.0, aplicable a los National Security Systems de Estados Unidos, refleja esa separación. Prevé el uso exclusivo de ML-KEM-1024 y ML-DSA-87 a finales de 2030 para la firma de software y firmware y para los equipos de red tradicionales, y a finales de 2033 para navegadores y servidores web, servicios en la nube y sistemas operativos.
Qué datos tienen una vida útil de confidencialidad lo bastante larga como para importar
La vida útil de confidencialidad es el periodo durante el cual una divulgación seguiría causando daño. Es una propiedad empresarial y jurídica de los datos, no una propiedad del protocolo, y es el único dato de entrada de la priorización HNDL que usted controla por completo. Para empezar bastan órdenes de magnitud.
| Categoría de datos | Por qué la vida útil es larga o corta | Orden de magnitud |
|---|---|---|
| Datos de salud, genómicos y biométricos | Identifican a una persona de por vida y no pueden reemitirse | Décadas |
| Material gubernamental, de defensa y diplomático | Los periodos de clasificación los fija la política, no la tecnología | Décadas |
| Secretos comerciales, fórmulas, diseños, código fuente | Su valor sigue la vida útil de la línea de producto | De años a décadas |
| Secreto profesional, expedientes de litigios, material del consejo y de operaciones corporativas | Sigue siendo sensible mucho después de cerrarse la operación o el caso | De años a décadas |
| Credenciales y material de claves en tránsito | Heredan la vida útil de aquello que desbloquean | Años |
| Datos personales conservados por obligaciones de retención | El daño persiste mientras existan los registros | Años |
| Precios en tiempo real, tokens de sesión breves, telemetría operativa | Su valor decae rápidamente tras la captura | De días a meses |
Dos correcciones que necesitan la mayoría de los inventarios. Primera: los datos de vida corta dentro de un túnel de vida larga heredan la del túnel; un enlace entre sedes que también transporta la replicación de una base de datos tiene la vida útil de esa base de datos. Segunda: los secretos en tránsito tienen la vida útil de los sistemas que abren, no la de la petición que los transportó.
Cómo priorizar los sistemas según la vida útil de sus datos
Para cada sistema, anote dos cifras. X es la vida útil de confidencialidad de los datos que transporta. Y es el tiempo que llevaría de forma realista migrar ese sistema, incluida la compatibilidad de clientes, el firmware de los appliances y las ventanas de cambio. Existe una tercera magnitud, el momento en que el cómputo pertinente sea factible, y nadie puede fecharlo de forma creíble, así que trátela como desconocida. La regla manejable es lo que queda: reducir Y, y dedicar ese esfuerzo primero donde X es mayor, porque el tráfico ya grabado no se puede recuperar.
| Nivel | Criterios | Acción |
|---|---|---|
| Actuar ya | Vida útil de confidencialidad superior a unos diez años, o el flujo transporta claves y credenciales, o atraviesa redes que usted no controla | Habilitar el acuerdo de claves híbrido ML-KEM en el transporte, preferir solo TLS 1.3, preferir AES-256 cuando la pila lo permita |
| Planificar a continuación | Vida útil de unos pocos años, tráfico interno que aun así transita por redes de proveedores o socios | Vincular el cambio a la próxima actualización de plataforma o de appliance, habilitar los grupos híbridos a medida que los clientes los admitan |
| Seguir a la plataforma | Vida útil inferior a un año, sin secretos ni identificadores de larga duración | Heredar los valores por defecto del sistema operativo, la biblioteca y el navegador |
Esta priorización necesita apoyarse en un inventario. El requisito 12.3.3 de PCI DSS v4.0.1, obligatorio desde el 31 de marzo de 2025, ya exige un inventario documentado de los conjuntos de cifrado y protocolos en uso, revisado al menos cada 12 meses, con seguimiento de su viabilidad continuada. Las normas técnicas de regulación de DORA, el Reglamento Delegado de la Comisión (EU) 2024/1774, exigen en su artículo 6 una política de cifrado que incluya disposiciones para actualizar o cambiar la tecnología criptográfica en función de los avances del criptoanálisis, y en su artículo 7 la gestión de claves a lo largo de todo su ciclo de vida, además de un registro de certificados para los activos que soportan funciones críticas o importantes. El artículo 21(2)(h) de NIS2 exige políticas sobre el uso de la criptografía. Ninguno de esos textos menciona una columna de vida útil de los datos: añadirla al inventario que usted ya mantiene es nuestra interpretación de una forma práctica de acreditar la priorización, no un requisito literal. Este artículo es informativo y no constituye asesoramiento jurídico.
Qué tienen en común los calendarios oficiales
Los calendarios publicados difieren en su naturaleza y en su redacción, y los matices importan. La Hoja de ruta de implementación coordinada de la UE v1.1 (publicada el 23 de junio de 2025) es una orientación coordinada para los Estados miembros, no un reglamento vinculante para las empresas: primeros pasos, incluidos un inventario criptográfico y hojas de ruta nacionales, a finales de 2026, casos de uso de alto riesgo migrados a finales de 2030 y de riesgo medio a finales de 2035. La guía del NCSC británico fija el descubrimiento y un plan inicial para 2028, las migraciones de máxima prioridad para 2031 y la finalización para 2035. La BSI TR-02102-1 (versión 2026-01) es una directriz técnica: recomienda el acuerdo de claves híbrido y considera aceptable el acuerdo de claves clásico usado en solitario solo hasta finales de 2031, o hasta finales de 2030 para necesidades de protección muy elevadas. NIST IR 8547 sigue siendo un borrador público inicial; propone declarar obsoletos los algoritmos vulnerables a la computación cuántica con seguridad de 112 bits después de 2030 y prohibir los algoritmos de clave pública vulnerables a la computación cuántica después de 2035. La ANSSI hace obligatoria la hibridación dentro de su ámbito regulado e indica que sus recomendaciones poscuánticas aún no son obligaciones reglamentarias fuera de él. Nuestra página sobre plazos de migración poscuántica reúne el detalle con fechas en un solo lugar.
La estructura común es más informativa que cualquier fecha aislada: un grupo de máxima prioridad hacia 2030 o 2031, el resto para 2035, y un criterio de selección del primer grupo que es, en esencia, la larga vida útil de los datos. Ese es el argumento HNDL, trasladado a la política pública.
Compruebe qué negocian realmente sus handshakes
Mida antes de planificar. Con OpenSSL 3.5 o posterior, que es la versión mínima que ofrece los grupos TLS ML-KEM, solicite explícitamente un grupo híbrido y lea lo que se ha negociado:
openssl s_client -connect example.com:443 -tls1_3 \
-groups X25519MLKEM768 </dev/null 2>&1 | grep -i groupPara el acceso administrativo, compruebe el acuerdo de claves de una sesión SSH. OpenSSH 9.9 (19 de septiembre de 2024) añadió mlkem768x25519-sha256, OpenSSH 10.0 (9 de abril de 2025) lo convirtió en el acuerdo de claves por defecto, y OpenSSH 10.1 (6 de octubre de 2025) avisa cuando una conexión negocia un acuerdo de claves no poscuántico, mediante WarnWeakCrypto, activado por defecto. Las notas de versión se publican en openssh.com.
ssh -v -o KexAlgorithms=mlkem768x25519-sha256 user@host 2>&1 | grep -i kexSitúe el grupo híbrido en primer lugar y mantenga detrás una alternativa clásica, por ejemplo X25519MLKEM768 y después X25519, para que los clientes más antiguos sigan conectándose. Pruebe en preproducción antes de pasar a producción y vigile el tamaño de los handshakes en enlaces con recursos limitados y en los appliances que inspeccionan el ClientHello.
Su siguiente paso
Empiece por los dos artefactos que hacen mecánico el resto: una columna de vida útil de los datos añadida a su inventario criptográfico y una medición de lo que negocian hoy sus endpoints externos. Para lo segundo puede analizar su dominio con PQC Status de forma gratuita: indica los grupos híbridos ML-KEM ofrecidos, las versiones de TLS y los conjuntos de cifrado, y la cadena de certificados. Un análisis describe únicamente la configuración TLS visible desde el exterior, así que trátelo como evidencia para su inventario, no como una certificación ni una declaración de cumplimiento. Después, tome los sistemas de su nivel de actuación inmediata y aplíqueles el acuerdo de claves híbrido, en ese orden.