Los estándares de criptografía postcuántica de NIST están finalizados — el reloj de migración corre

NIST finalizó tres estándares de criptografía postcuántica en agosto de 2024: ML-KEM (FIPS 203, basado en CRYSTALS-Kyber), ML-DSA (FIPS 204, basado en CRYSTALS-Dilithium) y SLH-DSA (FIPS 205, basado en SPHINCS+). Tras una década de evaluación y múltiples rondas de algoritmos, estos están listos para producción. El reloj de migración comenzó el día en que se publicaron los estándares, no el día en que lleguen las computadoras cuánticas.

El calendario práctico no es abstracto. El gobierno de EE.UU. ha exigido que las agencias federales inicien la migración a PQC para 2030 en la mayoría de los sistemas, y que la infraestructura clasificada se mueva antes. La industria ya va adelantada: Google Chrome envió ML-KEM híbrido en TLS en 2023 y desde entonces se ha actualizado a la versión final FIPS 203. Apple añadió PQC a iMessage con iOS 17.4. Signal actualizó su protocolo en 2024. Si operas infraestructura que debe permanecer segura durante 10+ años — especialmente cualquier cosa que implique intercambio de claves asimétricas — la migración no es opcional.

Harvest-Now-Decrypt-Later es una amenaza activa

La razón por la que la urgencia importa ahora, aunque aún no existan computadoras cuánticas criptográficamente relevantes, es el ataque de cosecha ahora, descifra después (HNDL). Adversarios a nivel de estado están capturando tráfico cifrado hoy con la intención de descifrarlo una vez que la capacidad cuántica esté disponible. Las estimaciones de NIST, NSA y CISA sitúan las computadoras cuánticas criptográficamente relevantes (CRQC) a 10–15 años de distancia — exactamente la ventana en la que los datos capturados en 2026 podrían descifrarse cuando aún tengan valor de inteligencia.

Si tu aplicación toca datos que deben mantenerse confidenciales durante una década — registros financieros, registros de salud, comunicaciones, propiedad intelectual, contratos gubernamentales — el adversario no necesita una computadora cuántica hoy. La necesita mientras a ti todavía te importe que esos datos sean secretos. La captura está ocurriendo ahora.

Triaje: qué migrar y cuándo

No todo necesita moverse simultáneamente. El orden de triaje correcto es: intercambio de claves primero, firmas segundo, cifrado simétrico al final (o nunca).

1. Intercambio de claves — máxima prioridad

El intercambio de claves RSA y ECDH es lo primero que las computadoras cuánticas rompen. Reemplázalos con ML-KEM (Kyber). La rampa de entrada segura estándar es el modo híbrido: ejecutar simultáneamente clásico y PQC. Si ML-KEM tiene una debilidad no descubierta, el algoritmo clásico aún te protege. Si aparece un CRQC, la capa PQC te cubre.

X25519MLKEM768 es el híbrido específico usado por Chrome, Cloudflare y AWS en TLS de producción hoy. Tu stack web puede que ya lo soporte: OpenSSL 3.5 (lanzado en abril de 2025) incluye soporte completo para ML-KEM y ML-DSA. Habilitarlo es típicamente un cambio de configuración, no de código.

2. Firmas digitales — prioridad media

ML-DSA (Dilithium) reemplaza a RSA-PSS y ECDSA para firmar. La urgencia aquí es menor porque las firmas no tienen el problema de HNDL — una firma solo necesita ser válida en el momento de la verificación, no dentro de una década. Coloca los certificados de firma de código, las firmas de documentos de larga duración y las jerarquías de CA internas en tu hoja de ruta 2027–2028, no en tu sprint de 2026.

3. Cifrado simétrico — prioridad baja

AES-256 y SHA-256 no son rotos por computadoras cuánticas. El algoritmo de Grover reduce a la mitad su longitud de clave efectiva, por lo que AES-256 ha sido la recomendación estándar durante años. Si ya estás usando claves simétricas de 256 bits, el cifrado simétrico no requiere migración. Si aún usas AES-128 por rendimiento, actualiza a AES-256 — ese es el alcance del trabajo aquí.

Madurez de librerías a mediados de 2026

El ecosistema ha convergido en los estándares FIPS finalizados en todos los lenguajes principales:

Go

El paquete estándar crypto/tls soporta X25519MLKEM768 a partir de Go 1.24. Para operaciones directas de ML-KEM fuera de TLS, golang.org/x/crypto incluye soporte estable para ML-KEM 768 y 1024. La API refleja los patrones de clave asimétrica existentes: GenerateKey, Encapsulate, Decapsulate con slices de bytes tipados.

Python

pyca/cryptography 44.0.0 (noviembre de 2024) añadió ML-KEM a través de su backend OpenSSL 3.5. La interfaz sigue el mismo patrón generate_private_key / exchange que las operaciones EC existentes. Para entornos donde no puedes controlar la versión de OpenSSL, pqcrypto proporciona un enlace directo a las implementaciones de referencia en C.

Rust

El crate ml-kem del proyecto RustCrypto es una implementación puramente en Rust, compatible con no_std y completamente conforme a FIPS 203. Soporta las variantes ML-KEM-512, 768 y 1024, y es la elección correcta para objetivos embebidos o WASM donde no se puede enlazar OpenSSL. Para puentear despliegues de Kyber anteriores al estándar, pqcrypto-kyber sigue disponible.

Java / JVM

BouncyCastle 1.77+ soporta ML-KEM y ML-DSA con una API estable. OpenJDK 24 introdujo ML-KEM como API de vista previa bajo JEP 496, con GA previsto para JDK 25. Para despliegues de producción en JVM hoy, BouncyCastle es la ruta fiable.

Habilitación de PQC híbrido en tu Service Mesh

Para mTLS interno entre servicios, el PQC híbrido se puede lograr sin cambios en el código de la aplicación. Envoy Proxy 1.32+ soporta el híbrido X25519+ML-KEM cuando se compila contra OpenSSL 3.5. El cambio es una actualización de configuración del service mesh en tu lista de suites de cifrado TLSParameters. Tanto Istio como Linkerd tienen rutas de migración documentadas para esta configuración.

Para TLS perimetral, Cloudflare y AWS CloudFront ya negocian X25519MLKEM768 cuando el cliente lo soporta. Si terminas TLS en una CDN o balanceador de carga que no controlas, revisa el changelog de tu proveedor — puede que ya tengas cobertura parcial de PQC sin saberlo.

Un cronograma concreto de tres años

2026: Audita todo el intercambio de claves en los servicios orientados al exterior. Identifica las versiones de OpenSSL en toda la flota. Habilita X25519MLKEM768 en los endpoints HTTPS (cambio de configuración). Documenta todo uso de RSA y ECDH en contextos no TLS: claves SSH, JWTs, PKI interno, cualquier derivación de clave personalizada.

2027: Migra el intercambio de claves no TLS a ML-KEM. Comienza el rediseño de la jerarquía de CA interna. Traslada la firma de código a ML-DSA para nuevas versiones de artefactos. Evalúa la migración de claves SSH (OpenSSH 9.x soporta KEX híbrido basado en ML-KEM).

2028–2030: Completa la migración de firmas. Retira RSA de toda infraestructura nueva. Logra la alineación con NIST SP 800-131C y los requisitos regulatorios aplicables (guías HIPAA, disposiciones PQC de PCI-DSS 5.0, estándares técnicos de la Ley de Ciberresiliencia de la UE).

Conclusiones prácticas

• Habilita X25519MLKEM768 en TLS 1.3 en los endpoints públicos hoy — es un cambio de configuración con una sobrecarga de rendimiento insignificante en hardware moderno, y protege contra HNDL de inmediato.
• Actualiza a OpenSSL 3.5+ o BouncyCastle 1.77+ antes de escribir cualquier nuevo código criptográfico; estos incluyen las implementaciones finales de FIPS 203, 204 y 205.
• Audita tu superficie de RSA y ECDH en TLS, SSH, firmado de JWT, PKI interno y cualquier intercambio de claves personalizado — el intercambio de claves es la prioridad más alta, las firmas son media, lo simétrico es la última.
• Usa el modo híbrido (clásico + PQC simultáneamente) como tu ruta de migración, no un corte directo a PQC puro; esto coincide con lo que Google, Cloudflare, AWS y Apple han desplegado.
• Si manejas datos con un requisito de confidencialidad de 10+ años, trata HNDL como una amenaza activa actual y pon la migración de intercambio de claves PQC en tu hoja de ruta de ingeniería de 2026, no en 2028.