NIST PQC: los estándares de criptografía post-cuántica
Índice de contenidos
- Puntos clave
- El problema que resuelven los estándares PQC
- Los tres estándares
- FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)
- FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)
- FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
- El quinto estándar: HQC
- Implementaciones disponibles
- La estrategia de migración: enfoque híbrido
- Crypto-agility: el prerequisito técnico
- La prioridad de migración
- Conclusión
Actualizado: 2026-05-03
En agosto de 2024, el NIST (National Institute of Standards and Technology) publicó los primeros estándares definitivos de criptografía post-cuántica: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA). Estos estándares están diseñados para sustituir a RSA y los esquemas basados en curvas elípticas cuando aparezca un ordenador cuántico lo suficientemente potente para ejecutar el algoritmo de Shor a escala. Este artículo explica los algoritmos, los plazos realistas y, sobre todo, cómo preparar tu stack de seguridad para la transición.
Puntos clave
- ML-KEM (FIPS 203) sustituye al intercambio de claves RSA/ECDH; ML-DSA (FIPS 204) a las firmas RSA/ECDSA; SLH-DSA (FIPS 205) es la alternativa basada en hash.
- El riesgo inmediato no es el ordenador cuántico —todavía no existe— sino el ataque «harvest now, decrypt later»: datos cifrados hoy pueden descifrarse en el futuro.
- Los secretos de larga vida (datos financieros, propiedad intelectual, sector público) son los más expuestos y deben priorizarse.
- La estrategia de transición recomendada es el enfoque híbrido: criptografía clásica + PQC en paralelo, para no depender de un solo esquema.
- Crypto-agility —diseñar sistemas donde los algoritmos criptográficos son intercambiables— es el prerequisito técnico para cualquier plan de migración.
El problema que resuelven los estándares PQC
El algoritmo de Shor (1994) demostró que un ordenador cuántico suficientemente grande puede factorizar enteros grandes en tiempo polinomial, lo que rompe RSA. El mismo ordenador puede resolver el problema del logaritmo discreto, lo que rompe los esquemas de curva elíptica (ECDH, ECDSA). Las máquinas cuánticas actuales no tienen la escala necesaria —el umbral estimado para romper RSA-2048 es del orden de millones de qubits lógicos tolerantes a fallos—, pero el horizonte no es indefinido.
El riesgo activo ya existe: el ataque «harvest now, decrypt later». Adversarios estatales o bien financiados pueden capturar tráfico cifrado con RSA o ECDH hoy y almacenarlo para descifrarlo cuando tengan el hardware cuántico. Para datos con ciclo de vida de 10-20 años —comunicaciones clasificadas, patentes, datos financieros, registros médicos— el riesgo es real ahora mismo, no en el futuro abstracto.
La transición criptográfica lleva entre 5 y 15 años en la industria. Sistemas de misión crítica, hardware embebido, cadenas de suministro de software: todo requiere tiempo para actualizar. Empezar ahora no es alarmismo —es gestión de riesgo responsable.
Los tres estándares
FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)
ML-KEM está basado en el esquema CRYSTALS-Kyber y sustituye al intercambio de claves Diffie-Hellman y ECDH. No es un algoritmo de cifrado en sí mismo; es un mecanismo de encapsulación de claves: genera una clave simétrica compartida entre dos partes sin que un observador pasivo pueda derivarla.
Tres variantes con distintos niveles de seguridad:
| Variante | Nivel de seguridad | Tamaño de clave pública | Tamaño de texto cifrado |
|---|---|---|---|
| ML-KEM-512 | ~128 bits clásicos | 800 bytes | 768 bytes |
| ML-KEM-768 | ~192 bits clásicos | 1.184 bytes | 1.088 bytes |
| ML-KEM-1024 | ~256 bits clásicos | 1.568 bytes | 1.568 bytes |
La recomendación para la mayoría de aplicaciones es ML-KEM-768: equilibra seguridad y tamaño de mensaje. ML-KEM-512 es para entornos con restricciones severas de ancho de banda; ML-KEM-1024 para casos que requieren el máximo nivel de seguridad.
FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)
ML-DSA está basado en CRYSTALS-Dilithium y sustituye a las firmas RSA y ECDSA. Las firmas digitales se usan en TLS para autenticar servidores, en el code signing para verificar software, en certificados X.509 y en JWT. ML-DSA tiene firmas más grandes que ECDSA pero sigue siendo manejable:
| Variante | Nivel de seguridad | Tamaño de clave pública | Tamaño de firma |
|---|---|---|---|
| ML-DSA-44 | ~128 bits clásicos | 1.312 bytes | 2.420 bytes |
| ML-DSA-65 | ~192 bits clásicos | 1.952 bytes | 3.293 bytes |
| ML-DSA-87 | ~256 bits clásicos | 2.592 bytes | 4.595 bytes |
Para comparar: una firma ECDSA P-256 ocupa 64 bytes. ML-DSA-44 ocupa 2.420 bytes. Este tamaño adicional tiene implicaciones en protocolos con limitaciones de MTU (UDP, algunos handshakes TLS en redes con baja MTU) que requieren atención durante la migración.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
SLH-DSA está basado en SPHINCS+ y ofrece una base matemática diferente a ML-DSA: la seguridad depende solo de las propiedades de las funciones hash criptográficas, no de problemas de retículo. Su ventaja es que es extremadamente conservador —si se descubriera una debilidad en los esquemas basados en retículo, SLH-DSA seguiría siendo seguro.
Las desventajas son firmas considerablemente más grandes (de ~8 KB a ~30 KB según la variante) y una generación de firmas más lenta. Su rol es de red de seguridad: no es la primera elección para la mayoría de aplicaciones, pero su existencia como alternativa reduce el riesgo sistémico de depender de un solo enfoque matemático.
El quinto estándar: HQC
El NIST también ha anunciado FIPS 207: HQC (Hamming Quasi-Cyclic), previsto para 2025, como KEM alternativo basado en teoría de códigos en lugar de retículos. Su propósito es dar redundancia: si se descubriera una debilidad en ML-KEM, HQC proporciona una alternativa ya estandarizada.
Implementaciones disponibles
La buena noticia es que las implementaciones ya están disponibles antes de que la mayoría de equipos necesiten migrar:
OpenSSL / BoringSSL: soporte experimental de ML-KEM en TLS 1.3 mediante ramas de desarrollo. La integración estable en OpenSSL está prevista para 2025. Chrome y Cloudflare ya tienen activado TLS híbrido (X25519 + ML-KEM-768) para millones de conexiones.
Go: crypto/mlkem768 está aterrizando en la stdlib. La librería liboqs-go de Open Quantum Safe ya está disponible como dependencia externa con todos los algoritmos estabilizados.
Rust: el crate pqcrypto cubre ML-KEM y ML-DSA. Implementaciones independientes como kyber-rust y dilithium-rust también están disponibles.
Python: bindings de pqcrypto con uso en producción todavía limitado. Para proyectos Python, la vía más robusta es llamar a OpenSSL via cryptography cuando el soporte se estabilice.
La estrategia de migración: enfoque híbrido
La migración directa de RSA/ECDH a ML-KEM pura conlleva el riesgo de apostar todo a un esquema criptográfico nuevo que, aunque ha superado años de revisión pública, no tiene el historial de producción de RSA. El enfoque recomendado es el híbrido:
- TLS 1.3 con
X25519Kyber768Draft00: usa ECDH X25519 Y ML-KEM-768 en paralelo. Para comprometer la sesión, un atacante tendría que romper ambos. Esto ya está activo en Chrome y Cloudflare. - Las firmas pueden migrar más gradualmente: ML-DSA puede combinarse con ECDSA en certificados híbridos durante el período de transición.
- El paso de híbrido a PQC puro vendrá cuando la confianza en los nuevos algoritmos sea suficientemente alta y el soporte en el ecosistema sea universal.
Crypto-agility: el prerequisito técnico
La lección más importante que transmite el NIST no es qué algoritmos usar, sino cómo diseñar sistemas que puedan cambiar de algoritmo. El patrón anti-agility más común:
MAL: RSA y SHA-256 codificados directamente en el código de aplicación
BIEN: interfaz abstracta "signer" e "encrypter" intercambiableUn sistema con crypto-agility puede migrar algoritmos con un cambio de configuración o de parámetro, sin reescribir la lógica de aplicación. Para equipos que gestionan infraestructura con certificados TLS vía Trivy y auditorías de seguridad, la crypto-agility es también una propiedad auditable: el inventario de primitivas criptográficas hardcoded es el primer paso del plan de migración.
Los pasos concretos:
- Inventariar todas las primitivas criptográficas codificadas a fuego en el código y en la configuración.
- Abstraer el uso de criptografía detrás de interfaces o librerías intercambiables.
- Elegir librerías que ya estén adoptando PQC (OpenSSL, BoringSSL, libsodium en roadmap).
- Gestión de claves: asegurarse de que el sistema de gestión de claves soporta rotación de algoritmo, no solo rotación de clave.
La prioridad de migración
No todo requiere la misma urgencia. El orden recomendado:
- Secretos de larga vida con riesgo «harvest now»: datos clasificados, IP sensible, datos financieros de clientes de largo plazo. Alta prioridad.
- TLS en edge: CDN, balanceadores, puntos de terminación TLS. El enfoque híbrido ya está disponible; activarlo tiene bajo riesgo.
- Firma de código y certificados: el ciclo de vida de las PKI hace que la migración sea más lenta; empezar el roadmap ahora.
- VPN y SSH: WireGuard tiene propuestas PQC; OpenSSH tiene soporte experimental de ML-KEM. Seguir el roadmap de los vendors.
- Sistemas legacy: hardware embebido, sistemas industriales. Los plazos son más largos; priorizar el inventario.
Conclusión
NIST PQC representa el cambio criptográfico más grande desde la adopción de RSA hace cuatro décadas. Los estándares están publicados, las implementaciones están llegando, y el riesgo «harvest now, decrypt later» es real para datos de larga vida hoy mismo. La respuesta correcta no es pánico ni parálisis: es inventariar, adoptar el enfoque híbrido en TLS ya disponible, diseñar sistemas con crypto-agility, y migrar por fases según la exposición al riesgo.
