Criptografía post-cuántica: qué es, riesgos y cómo iniciar la migración

Qué es la PQC y qué no es

La criptografía post-cuántica (PQC) es el conjunto de algoritmos de clave pública diseñados para resistir ataques de ordenadores cuánticos. Sustituyen (o complementan durante un tiempo) a RSA y ECC, que quedarían vulnerables ante un adversario con suficiente capacidad cuántica por el algoritmo de Shor. La idea clave: seguimos con criptografía basada en problemas matemáticos duros, pero cambiamos de familia de problemas (retículos, hash, códigos, multivariantes, etc.). La PQC no es “criptografía cuántica”: esta última usa fenómenos cuánticos (p. ej., QKD) y es otra disciplina distinta. Si solo quieres asegurar tus webs, APIs, email, VPN, software firmado, la ruta estándar es PQC, no QKD.

La urgencia no es teórica. Existe el riesgo “Harvest-Now, Decrypt-Later (HNDL)”: atacantes que capturan hoy datos cifrados para descifrarlos cuando la computación cuántica sea viable a gran escala. La defensa sensata es empezar a introducir PQC desde ya en los puntos donde más duele que te descifren el tráfico o los artefactos firmados a futuro.

PQC vs criptografía cuántica (diferencias claras)

• PQC: algoritmos clásicos resistentes a cuántica; se implementan en software/hardware estándar (TLS, IPsec, PKI).
• Criptografía cuántica: usa física cuántica (p. ej., QKD). Requiere equipamiento especializado y resuelve un subconjunto de problemas. Para la mayoría de organizaciones, PQC es la vía práctica.

Amenaza HNDL: por qué ya es un riesgo

Si tus datos tienen vida útil (compliance, propiedad intelectual, salud, finanzas), no quieres que lo que viaja hoy en TLS pueda leerse en 5–10 años. Mitigar HNDL implica priorizar confidencialidad en tránsito y firmas a largo plazo con algoritmos reconocidos por estándares actuales.

Qué está estandarizando NIST

En agosto de 2024, NIST publicó los tres primeros estándares FIPS para PQC y anima a empezar la transición. Nombres finales:

• FIPS 203 – ML-KEM (basado en Kyber): encapsulación de claves (KEM) para confidencialidad.
• FIPS 204 – ML-DSA (basado en Dilithium): firmas digitales de propósito general.
• FIPS 205 – SLH-DSA (basado en SPHINCS+): firmas hash-basadas como alternativa de distinta base matemática.

Además, el ecosistema se completa con guías NIST (p. ej., SP 800-208 para LMS/XMSS en firmado de firmware) y trabajos en curso en IETF/ETSI para operativa híbrida.

ML-KEM (confidencialidad)

Es el KEM recomendado para proteger el intercambio de claves en protocolos como TLS 1.3 o IPsec y así blindar el tráfico frente a HNDL. Está pensado para sustituir (o convivir durante la transición) con ECDHE/X25519.

ML-DSA y SLH-DSA (autenticación y firma)

ML-DSA cubre la mayoría de casos de firma (certificados, binarios, objetos de repositorio). SLH-DSA ofrece una alternativa hash-basada, útil como “plan B” y para perfiles con requisitos de seguridad conservadores.

Compatibilidad con TLS/PKI actuales

La transición se facilita con modos híbridos (combinar clásico+PQC), ya definidos a nivel de principios en RFC 9794 y con construcciones concretas en ETSI. En la práctica, hoy ya se usa X25519+ML-KEM-768 en TLS en grandes redes, y hay guías para integrarlo en PKI.

Cómo empezar la migración (checklist accionable)

Inventario criptográfico y “crypto-BOM”

1. Descubre dónde usas criptografía de clave pública: TLS (externo/interno), VPN (IKEv2), email (S/MIME), firmware/code-signing, repositorios, backups, apps móviles/IoT.
2. Clasifica datos por vida útil y sensibilidad (qué podría explotar HNDL).
3. Mapa de dependencias: librerías (OpenSSL, BoringSSL, wolfSSL), HSM, módulos FIPS, gateways TLS, WAF/CDN, proxies, balanceadores, endpoints.
4. Activa cripto-agilidad: evita algoritmos hardcodeados; soporta múltiples suites y rotación sin recompilar. (NIST enfatiza cripto-agilidad en su orientación de transición).

Pilotos con TLS/PKI híbridos (qué medir)

• En TLS: habilita X25519+ML-KEM-768 en entornos de prueba; mide latencia de handshake, tamaño de mensajes y fallos de compatibilidad por middleboxes. Grandes proveedores reportan despliegue amplio de esta combinación.
• En PKI: prepara CA y perfiles X.509 para ML-DSA/SLH-DSA (o composiciones híbridas cuando aplique). Sigue las propuestas y borradores del grupo LAMPS para certificados/objetos híbridos.
• Criterios de éxito: compatibilidad cliente/servidor, impacto en CPU/RAM, tamaño de certificados/cadenas, telemetría de errores.

Gestión de claves, rotación y caducidades

• Rota a menudo durante pilotos y mantén roll-back listo.
• Segmenta por riesgo: primero frontales web críticas (HNDL), luego túneles internos, después correo/firmas de código.
• Firma de firmware/raíz de confianza: evalúa LMS/XMSS (SP 800-208) para objetos de larga vida.

Rendimiento, tamaños y trade-offs reales

• Tamaños mayores: claves, firmas y certificados PQC crecen; planifica para MTU/fragmentación, caches TLS y almacenamiento de certificados. (Evita suposiciones: mide en tu red).
• CPU y latencia: los handshakes con ML-KEM y verificación de ML-DSA son rápidos en la mayoría de CPUs modernas, pero las firmas y dispositivos IoT pueden requerir tuning.
• Estrategias:
  • Prefiere ML-KEM-768 en web pública si el objetivo es abarcar el mayor parque de clientes que ya lo soportan en modo híbrido.
  • Ajusta TLS 1.3 (re-use de sesión, 0-RTT con cautela), cachés de OCSP/CRL y cadenas más cortas para compensar el aumento de bytes.
  • En firmado de código/firmware, considera LMS/XMSS o SLH-DSA para artefactos longevos.

Servidor, cliente y dispositivos/IoT

• Servidores: revisa soporte OpenSSL/BoringSSL, compatibilidad en HSM y módulos validados FIPS cuando aplique.
• Clientes: actualiza navegadores/SDKs y activa telemetría para ver qué suites híbridas negocian realmente.
• IoT/OT: valora FN-DSA/Falcon cuando esté disponible si necesitas firmas compactas; mientras tanto, planifica ciclos de actualización de firmware. (NIST ya señaló el plan de FIPS para Falcon como FN-DSA).

Estrategias de caché y tuning

• Cachea cadenas y stapling OCSP para mitigar bytes extra.
• Revisa MTU en túneles (IPsec/QUIC) y activa PMTUD/fragmentación segura.
• Observa retry rates de handshake cuando actives híbridos.

Errores frecuentes y cómo evitarlos

• Confundir PQC con “cuántica”: son caminos distintos; PQC es la vía estándar para TLS/PKI.
• Ignorar HNDL: si tus datos “viven” años, posponer PQC es aceptar que podrían leerse en el futuro. Empieza por tráfico externo y backups críticos.
• Migrar sin cripto-agilidad: bloquea futuras transiciones. Prepara multi-algoritmo y actualizaciones sin downtime.
• Saltarse el modo híbrido donde ayuda: la terminología y patrones híbridos ya están normalizados (RFC 9794, ETSI TS 103 744); úsalos donde den compatibilidad y defensa en profundidad.

Normativa y plazos que marcan el ritmo (visión 2025)

• NIST: FIPS 203/204/205 finales (13-ago-2024, actualizados 29-ago-2025). Recomienda iniciar la transición; Falcon llegará como FN-DSA en un FIPS posterior.
• IETF: RFC 9794 fija lenguaje común para esquemas híbridos (jun-2025).
• ETSI: TS 103 744 v1.2.1 (mar-2025) define métodos para derivar claves a partir de múltiples secretos (híbridos) y orienta la migración.
• Panorama de adopción: operadores de gran escala informan que X25519MLKEM768 está listo y ampliamente desplegado en TLS; IPsec también va adoptando híbridos. Úsalo como señal de madurez para tus pilotos.

FAQs rápidas

¿En qué se diferencia PQC de la criptografía cuántica?
PQC = algoritmos clásicos resistentes a cuántica; criptografía cuántica = usa física cuántica (p. ej., QKD). Rutas y requisitos distintos.

¿Cuáles son los estándares PQC “oficiales” hoy?
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA); para firmware: SP 800-208 (LMS/XMSS).

¿Qué es HNDL y por qué importa ya?
Riesgo de “cosechar ahora y descifrar después”. Si tus datos duran años, debes migrar cuanto antes en los puntos críticos.

¿Debo migrar todo ya o empezar por críticos?
Empieza por servicios expuestos, túneles y firmas longevas, con pilotos híbridos medibles.

¿PQC rompe TLS/HTTP?
No. TLS 1.3 soporta híbridos que combinan PQC con X25519/ECDHE y ya están en producción en grandes redes.

¿Qué pasa con RSA/ECC durante la transición?
Seguirán conviviendo en modos híbridos y poco a poco irán quedando en desuso a medida que clientes/servidores soporten PQC puro.

Conclusión

La buena noticia es que ya no hablamos de “teoría”: hay estándares finales (FIPS 203/204/205), lenguaje común para híbridos (RFC 9794) y despliegues reales (X25519+ML-KEM-768 en TLS). Mi recomendación práctica es inventariar, pilotar híbridos y medir, empezando por lo más expuesto y lo más longevo. Con cripto-agilidad desde el diseño, podrás adoptar nuevas guías/algoritmos sin rehacer tu plataforma.