Estándares NIST PQC finales: qué hacer con ellos ahora
Actualizado: 2026-05-03
El NIST publicó en agosto de 2024 los tres estándares definitivos de criptografía post-cuántica:
- FIPS 203 (ML-KEM, basado en CRYSTALS-Kyber)
- FIPS 204 (ML-DSA, basado en CRYSTALS-Dilithium)
- FIPS 205 (SLH-DSA, basado en SPHINCS+)
Medio año después, el titular ya no es noticia y toca convertirlo en plan. Este post recoge lo que he visto funcionar y lo que no en equipos que están empezando la transición, con la idea de ayudar a separar lo urgente de lo que puede esperar.
Puntos clave
- No hay aún un ordenador cuántico capaz de romper RSA-2048. El riesgo real hoy es «harvest now, decrypt later»: adversarios interceptan datos cifrados hoy para descifrarlos mañana.
- El primer paso es el más ignorado: inventario criptográfico honesto por capas (comunicaciones externas, PKI interna, datos en reposo, proveedores).
- El error más frecuente es reemplazar algoritmos uno por uno en lugar de construir cripto-agilidad: arquitecturas que permiten cambiar el algoritmo sin reescribir la aplicación.
- La táctica que más ha cuajado: algoritmos híbridos (ECDHE + ML-KEM) en comunicaciones externas, criptografía clásica en el resto por ahora.
- Las firmas PQC (ML-DSA, SLH-DSA) son órdenes de magnitud mayores que ECDSA: un certificado X.509 con ML-DSA crece de 1-2 KB a 4-6 KB.
Lo primero: orden de magnitud
Lo primero que conviene asentar es el orden de magnitud. No hay aún un ordenador cuántico capaz de romper RSA-2048 o ECDSA P-256. Las estimaciones serias sobre cuándo lo habrá varían entre una década y nunca, y la honestidad profesional obliga a reconocer que no lo sabemos. Pero sí sabemos que adversarios con paciencia pueden interceptar hoy y descifrar mañana. Para datos con valor a largo plazo, la transición no es opcional.
El inventario que casi nadie tiene
El primer paso es el más aburrido y el más ignorado: saber dónde está la criptografía en tu organización. No se trata solo de TLS en las webs públicas. Se trata de:
- VPN entre oficinas
- Certificados de clientes en máquinas IoT
- Firmas en actualizaciones de firmware
- JWT en APIs internas
- Cifrado en reposo de bases de datos
- Claves SSH de los servidores de administración
- Correo firmado S/MIME
- Integridad de logs de auditoría
Lo sensato es abordarlo por capas: primero las comunicaciones externas con terceros, luego la infraestructura interna (VPN, PKI propia), después los datos en reposo con retención alta, y por último las integraciones con proveedores (donde más dolor hay porque no controlas el calendario del otro lado).
Una herramienta útil para empezar es pqc-iq de IBM, que escanea aplicaciones Java en busca de usos criptográficos, y los scripts que la comunidad ha publicado para analizar certificados X.509.
Cripto-agilidad antes que cripto-correcta
El error más frecuente que veo en los primeros arranques es querer reemplazar algoritmos uno por uno. Se parchea una aplicación con ML-KEM y se deja el resto para después. Es tentador porque produce un tick en el informe, pero suele ser un error.
La conversación que rinde más es la de cripto-agilidad. En lugar de preguntar «¿qué algoritmo usamos?», preguntar «¿cómo cambiamos el algoritmo sin reescribir la aplicación?». Eso obliga a revisar:
- Dónde se instancia el proveedor criptográfico.
- Si los formatos en disco y en red llevan identificadores de algoritmo.
- Si la configuración está externalizada.
- Si hay cadenas de compatibilidad para leer cifrado antiguo mientras se escribe con el nuevo.
Un sistema cripto-ágil bien diseñado hoy absorbe sin drama la primera transición a PQC, y absorberá también la segunda cuando los algoritmos actuales muestren debilidades.
Híbridos en lo externo, clásico en lo interno
La táctica que más ha cuajado en despliegues serios es usar algoritmos híbridos en los intercambios de clave de comunicaciones, y dejar el resto con criptografía clásica por ahora. Un híbrido combina ECDHE clásico con ML-KEM en la misma negociación, de modo que un atacante necesita romper los dos para tener éxito.
Cloudflare, Google y AWS ya soportan híbridos en sus extremos de TLS, y OpenSSH 9.9 estrenó la negociación híbrida en 2024 con el KEM sntrup761x25519. En 2025 muchos clientes lo usan sin saberlo.
Para firmas digitales (ML-DSA o SLH-DSA), los híbridos son más complicados y la recomendación suele ser esperar un poco más antes de cambiar certificados de firma de código o firmas S/MIME, porque los tamaños son significativos y la infraestructura PKI no está lista.
Para cifrado simétrico en reposo, no hace falta urgencia: AES-256 sigue siendo seguro frente a adversarios cuánticos con el algoritmo de Grover, que reduce la seguridad efectiva a 128 bits (razonable).
Tamaños, latencias y presupuestos
Los estándares PQC no son drop-in. Los tamaños de clave y firma son órdenes de magnitud mayores:
| Algoritmo | Clave pública | Firma |
|---|---|---|
| ECDSA P-256 | 64 bytes | 64 bytes |
| Ed25519 | 32 bytes | 64 bytes |
| ML-KEM-768 | 1.184 bytes | — |
| ML-DSA-65 | 1.952 bytes | 3.309 bytes |
| SLH-DSA (mínimo) | 32 bytes | 7.856 bytes |
Un certificado X.509 con ML-DSA crece de 1-2 KB a 4-6 KB. Una cadena completa TLS con tres certificados post-cuánticos se acerca a los 20 KB. En enlaces lentos (IoT celular, satélite) esto se nota.
Para más contexto sobre la adopción de PQC en TLS y SSH, ver nuestra guía de PQC en SSH y PQC en TLS: adopción.
El cronograma que tiene sentido
Mi sugerencia para un plan realista se parece a esto:
- Primer trimestre: inventario criptográfico honesto.
- Segundo trimestre: habilitar híbridos en TLS en todos los balanceadores y en el correo saliente cuando el partner lo soporte.
- Segundo semestre: revisar la PKI interna y planificar una jerarquía post-cuántica para 2026-2027, sin prisa.
- En paralelo: adoptar cripto-agilidad como requisito en todo código nuevo.
A medio plazo, los reguladores van a empujar. El BSI alemán tiene recomendaciones desde 2020, la ANSSI francesa se movió en 2022 y la CNSA 2.0 americana fijó objetivos para 2035. La Unión Europea, a través de ENISA, publicó una guía actualizada a finales de 2024 que varios gobiernos están adoptando.
Cómo pensar la decisión
Lo más valioso que he aprendido estos meses es que la transición post-cuántica es una excusa perfecta para hacer algo que ya necesitabas: ordenar la criptografía de tu organización. La mayoría de los equipos que se ponen hoy descubren durante el inventario que tenían claves RSA-1024 olvidadas, certificados con SHA-1, librerías desactualizadas o secretos hardcodeados. El PQC entra después; el orden previo es lo que realmente sube la seguridad.
La tentación es tratarlo como un proyecto de compliance, con una fecha y un tick. Y se puede hacer así, pero es caro y frágil. Tratarlo como una oportunidad para invertir en cripto-agilidad, higiene criptográfica y documentación es más rentable a medio plazo.
Y si tu reacción ante todo esto es «lo dejamos para cuando aparezca un ordenador cuántico», recuerda el harvest now, decrypt later. Para actas jurídicas, historiales médicos, secretos comerciales o comunicaciones diplomáticas, la transición no es opcional, es cuestión de fechas.
