Los estándares poscuánticos del NIST ya están aquí. Tu infraestructura no está lista.
En agosto de 2024, el Instituto Nacional de Estándares y Tecnología (NIST) publicó tres estándares finalizados de criptografía poscuántica (PQC): FIPS 203 (ML-KEM, basado en CRYSTALS-Kyber), FIPS 204 (ML-DSA, basado en CRYSTALS-Dilithium) y FIPS 205 (SLH-DSA, basado en SPHINCS+). Representan la culminación de un proceso de estandarización de ocho años que comenzó en 2016. Los estándares existen. El modelo de amenaza es real. Lo que aún no ha sucedido es una migración significativa de la infraestructura real de Internet.
Los algoritmos criptográficos que protegen la mayor parte de Internet hoy en día — RSA-2048, ECDH P-256, ECDSA — dependen de problemas matemáticos (factorización de enteros y logaritmo discreto) que las computadoras clásicas no pueden resolver de manera eficiente. Una computadora cuántica criptográficamente relevante (CRQC) que ejecute el algoritmo de Shor podría romperlos en horas. No existe tal máquina hoy, pero la amenaza de "cosechar ahora, descifrar después" ya está activa: actores estatales están recopilando tráfico cifrado hoy con la intención de descifrarlo una vez que el hardware cuántico madure.
Lo que el NIST realmente estandarizó
FIPS 203 / ML-KEM es el mecanismo de encapsulación de claves principal para el cifrado general y el intercambio de claves — el reemplazo directo de RSA y ECDH en protocolos como TLS. Ofrece tres conjuntos de parámetros: ML-KEM-512, ML-KEM-768 y ML-KEM-1024, equilibrando el nivel de seguridad con los tamaños de clave y texto cifrado. ML-KEM-768 se considera el valor predeterminado práctico, ofreciendo una seguridad comparable a AES-192.
FIPS 204 / ML-DSA maneja las firmas digitales, reemplazando a RSA y ECDSA en cadenas de certificados, firma de código y sistemas de autenticación. Al igual que ML-KEM, viene en tres variantes de parámetros (ML-DSA-44, ML-DSA-65, ML-DSA-87). El inconveniente: las firmas ML-DSA son significativamente más grandes que las firmas ECDSA — ML-DSA-65 produce firmas de 3.309 bytes frente a los 64–72 bytes de ECDSA. Esto tiene implicaciones reales para los tamaños de las cadenas de certificados en los handshakes TLS.
FIPS 205 / SLH-DSA es un esquema de firma basado en hash sin estado, más conservador en sus supuestos de seguridad que ML-DSA ya que se basa únicamente en la seguridad de la función hash en lugar de problemas de retículos. Es más lento y produce firmas más grandes, lo que lo hace más adecuado para firmas de larga duración en certificados raíz y firmware que para autenticación de alto rendimiento.
Dónde está realmente Internet hoy
La compatibilidad del navegador con el intercambio de claves híbrido llegó antes de que los estándares estuvieran finalizados. Chrome habilitó X25519Kyber768 (un híbrido que combina ECDH clásico con Kyber) de forma predeterminada en Chrome 124 (abril de 2024). Cloudflare y Google han estado ejecutando PQC híbrido para TLS desde finales de 2023 en su infraestructura periférica. Pero esto cubre solo el intercambio de claves — las cadenas de certificados que validan la identidad del servidor todavía usan ECDSA o RSA en su totalidad.
El ecosistema de certificados está esencialmente sin migrar. Los aproximadamente 200 millones de certificados TLS activos en uso a mediados de 2025 son abrumadoramente ECDSA o RSA. Las autoridades de certificación, incluidas DigiCert y Let's Encrypt, han comenzado a probar la emisión de certificados PQC, pero aún no han implementado certificados PQC de producción a gran escala. El problema se está agravando: los certificados PQC con firmas ML-DSA aumentarían sustancialmente los tamaños de los handshakes TLS, potencialmente rompiendo clientes con límites estrictos de tamaño de paquete o afectando el rendimiento en conexiones de alta latencia.
Los protocolos VPN también están rezagados. Las implementaciones de WireGuard, OpenVPN e IPsec/IKEv2 varían ampliamente en el soporte de PQC. OpenSSH agregó soporte para el intercambio de claves híbrido sntrup761x25519-sha512 en la versión 8.5 (2021) y lo convirtió en el predeterminado en la 9.0 (2022), convirtiéndose en una de las primeras integraciones de PQC ampliamente implementadas. Pero los productos VPN utilizados en entornos empresariales — Cisco, Palo Alto, Fortinet — tienen cronogramas variables, y muchos aún planifican el soporte PQC para 2026–2027.
El cronograma que enfrentan las organizaciones
El cronograma del gobierno estadounidense es el más prescriptivo. El Conjunto de Algoritmos de Seguridad Nacional Comercial 2.0 (CNSA 2.0) de la NSA exige la migración a PQC para los sistemas de seguridad nacional, con plazos diferentes según el tipo de sistema. Firma de software y firmware: para 2025. Equipos de red: para 2026. Sistemas operativos: para 2027. La mayoría de los sistemas gubernamentales clasificados y sensibles: para 2033. La propia guía del NIST en la Publicación Especial 1800-38B proporciona una hoja de ruta de migración para agencias federales con plazos similares.
Para las organizaciones privadas, aún no existe un mandato regulatorio, pero eso está cambiando. La directiva NIS2 de la UE incluye requisitos de agilidad criptográfica, y ENISA (la Agencia de la UE para la Ciberseguridad) ha publicado pautas de migración a PQC que recomiendan a las organizaciones completar las fases de inventario y planificación para 2025 y comenzar la migración activa para 2026. Los reguladores del sector financiero en el Reino Unido y la UE han emitido pautas similares.
La ventana de "cosechar ahora, descifrar después" es el motor crítico para la priorización. Cualquier dato con un requisito de confidencialidad superior a 5–10 años debe tratarse como ya en riesgo si se transmite hoy con criptografía clásica. Los registros médicos, los acuerdos financieros, la propiedad intelectual y las comunicaciones clasificadas entran en esta categoría.
Los desafíos técnicos que implica realmente la migración
La migración a PQC no es un simple reemplazo. Los tamaños más grandes de claves y firmas en los algoritmos poscuánticos crean problemas de compatibilidad en cascada. Las claves públicas de ML-KEM-768 son 1.184 bytes en comparación con los 32 bytes de X25519. Las claves públicas de ML-DSA-65 son 1.952 bytes. Los protocolos con encabezados de tamaño fijo, los módulos de seguridad de hardware con límites de tamaño de clave y el firmware de HSM anterior a PQC requieren actualizaciones o reemplazo.
Las bibliotecas criptográficas están por delante de la mayoría de las aplicaciones. OpenSSL 3.x admite PQC a través del proveedor Open Quantum Safe (OQS). BoringSSL (utilizado por Chrome y Android) ha integrado Kyber. La biblioteca liboqs validada por NIST proporciona implementaciones de referencia. Pero integrarlas en sistemas de producción requiere pruebas de regresión de rendimiento, especialmente en sistemas integrados y dispositivos IoT restringidos donde la sobrecarga computacional de ML-KEM puede ser significativa.
La infraestructura de la autoridad de certificación necesita actualizaciones sustanciales. La emisión de certificados PQC requiere actualizar el software de la CA, los HSM capaces de realizar operaciones ML-DSA, los respondedores OCSP y los puntos de distribución CRL. Toda la cadena PKI — CA raíz, CA intermedias, certificados hoja — debe migrar de manera coordinada que mantenga la compatibilidad hacia atrás durante un período de transición que podría durar una década.
Lo que las organizaciones deben hacer ahora
Realizar un inventario criptográfico. Mapea cada sistema, servicio y flujo de datos que utilice criptografía de clave pública. Esto incluye endpoints TLS, VPN, infraestructura SSH, canalizaciones de firma de código, sistemas PKI, bases de datos cifradas y cualquier HSM o tarjeta inteligente. NIST SP 1800-38B proporciona una metodología detallada para este proceso de inventario.
Priorizar por sensibilidad y longevidad de los datos. Los sistemas que transmiten o almacenan datos que requieren confidencialidad más allá de 2030 deben estar al principio de la cola de migración. Los ataques de cosechar-ahora-descifrar-después hacen que la amenaza sea real hoy, aunque la computadora cuántica aún no exista.
Habilitar la criptografía híbrida donde esté disponible. Los modos híbridos (clásico + PQC) brindan resistencia cuántica sin sacrificar la seguridad clásica si el algoritmo PQC resulta tener vulnerabilidades. El RFC 9370 de IETF estandariza el intercambio de claves híbrido para TLS 1.3. La mayoría de las bibliotecas TLS modernas admiten el modo híbrido X25519MLKEM768 hoy.
Actualizar las dependencias de la biblioteca criptográfica. Actualiza a OpenSSL 3.3+, compilaciones de BoringSSL posteriores a enero de 2024, o equivalente con soporte del proveedor OQS. Audita cualquier código criptológico integrado o aceleración de hardware que pueda tener supuestos de algoritmos clásicos codificados.
Contacta a tu autoridad de certificación y a los proveedores de PKI. Pregunta a DigiCert, Sectigo, Let's Encrypt y a los operadores de CA internos sobre sus hojas de ruta de migración a PQC y compromisos de cronograma. Incorpora esas fechas en tus propios horizontes de planificación.
Planificar pruebas de rendimiento. Los algoritmos PQC no son uniformemente más lentos, pero son diferentes. ML-KEM es rápido en software; las firmas basadas en hash como SLH-DSA son lentas. Evalúa tus cargas de trabajo específicas, especialmente cualquier cosa que realice altos volúmenes de verificación de firmas, como un CDN, un balanceador de carga o un servicio de autenticación a gran escala.
La amenaza cuántica no es inminente en el sentido de que "existirá un CRQC el próximo año". Las estimaciones creíbles de IBM, Google e investigadores académicos sitúan la computación cuántica criptográficamente relevante en un mínimo de 10 a 15 años según las trayectorias actuales. Pero las migraciones criptográficas toman de 5 a 15 años para completarse en infraestructuras complejas. NIST publicó los estándares. El reloj de la migración comenzó. Las organizaciones que comiencen ahora la planificación sistemática y la migración temprana evitarán situaciones de crisis cuando lleguen los plazos regulatorios, o cuando un avance en la computación cuántica mueva el cronograma.