La criptografía post-cuántica ya no es teoría: su hoja de ruta de migración
En agosto de 2024, el NIST publicó los primeros estándares finalizados de criptografía post-cuántica de su historia: FIPS 203 (ML-KEM, basado en CRYSTALS-Kyber), FIPS 204 (ML-DSA, basado en CRYSTALS-Dilithium) y FIPS 205 (SLH-DSA, basado en SPHINCS+). Estos estándares cierran un proceso de estandarización de varios años que incluyó competencia criptográfica global, revisión pública y múltiples rondas de criptoanálisis. La criptografía post-cuántica ya no es un problema de investigación: es un problema de ingeniería y migración.
Por qué la urgencia es real ahora, no dentro de 10 años
El marco habitual en torno a la criptografía post-cuántica sugiere que la migración puede esperar hasta que las computadoras cuánticas sean lo suficientemente potentes para romper RSA y la criptografía de curva elíptica — una capacidad que la mayoría de las estimaciones sitúa a 10–20 años. Ese marco es peligrosamente incorrecto, y la razón es un modelo de amenaza llamado «cosechar ahora, descifrar después» (HNDL).
Adversarios estatales y actores de amenazas sofisticados ya están recopilando tráfico de red cifrado hoy. Las sesiones TLS, los túneles VPN, el correo electrónico cifrado y las llamadas API sensibles se están grabando y almacenando. Los datos cifrados son ininteligibles hoy, pero si una computadora cuántica suficientemente potente estuviera disponible en 2035 o 2040, ese tráfico almacenado podría descifrarse retroactivamente.
Esto significa que los datos cifrados hoy con RSA-2048 o ECDH P-256 — si aún deben permanecer secretos dentro de 15 años — están efectivamente comprometidos desde una perspectiva de confidencialidad a largo plazo. Las comunicaciones gubernamentales, los datos de seguridad nacional, los historiales de transacciones financieras, los registros sanitarios y los acuerdos contractuales de larga duración caen en esta categoría. Para las organizaciones con requisitos de clasificación de datos prolongados, el reloj de migración comenzó a correr hace años.
Qué especifican realmente los estándares del NIST
Los tres estándares finalizados cubren diferentes funciones criptográficas:
FIPS 203 / ML-KEM (antes CRYSTALS-Kyber) es un mecanismo de encapsulación de claves — el reemplazo resistente a cuánticos para el intercambio de claves RSA y Diffie-Hellman en protocolos como TLS. Se basa en la dureza del problema Module Learning With Errors, una estructura matemática basada en retículos que se cree resistente tanto a ataques clásicos como cuánticos. ML-KEM viene en tres conjuntos de parámetros: ML-KEM-512 (seguridad comparable a AES-128), ML-KEM-768 (comparable a AES-192) y ML-KEM-1024 (comparable a AES-256).
FIPS 204 / ML-DSA (antes CRYSTALS-Dilithium) es un esquema de firma digital — el reemplazo de las firmas ECDSA y RSA utilizadas en la firma de código, las autoridades de certificación, la firma de correo electrónico y los tokens de autenticación. También basado en retículos, ofrece una seguridad sólida con tamaños de clave y firma relativamente compactos.
FIPS 205 / SLH-DSA (antes SPHINCS+) es un esquema de firma basado en hash. Las firmas basadas en hash tienen un historial más largo de escrutinio criptoanalítico que los esquemas basados en retículos, lo que convierte a SLH-DSA en una opción de respaldo conservadora para organizaciones que desean diversidad en sus fundamentos criptográficos. La contrapartida son tamaños de firma más grandes.
El NIST también está estandarizando FALCON (ahora FN-DSA) como un cuarto esquema de firma optimizado para entornos restringidos. Ofrece firmas más pequeñas que ML-DSA pero tiene requisitos de implementación más complejos.
La complejidad de migración que la mayoría de las organizaciones subestima
La migración criptográfica suena como un intercambio de librerías — reemplazar los algoritmos antiguos por otros nuevos — pero en la práctica se acerca más a una auditoría de infraestructura que dura varios años. La criptografía está incrustada en cada capa del stack de una organización: cadenas de certificados TLS, claves de host SSH, pipelines de firma de código, módulos de seguridad de hardware (HSM), firma de firmware, cifrado de correo S/MIME, protocolos VPN, claves de firma JWT, cifrado de bases de datos, cifrado de copias de seguridad, y más.
Muchos de estos sistemas no exponen parámetros de configuración sencillos para cambiar de familia de algoritmos. Los HSM requieren actualizaciones de firmware o reemplazo de hardware para admitir nuevos algoritmos. Las autoridades de certificación y la infraestructura PKI necesitan ser reconstruidas o actualizadas. Los proveedores y socios upstream y downstream deben admitir los mismos algoritmos para que la autenticación mutua funcione. Los sistemas de control industrial, los dispositivos embebidos y el hardware IoT con vidas operativas de 10 a 15 años puede que nunca reciban firmware resistente a cuánticos.
El principio de crypto-agility — diseñar sistemas para intercambiar primitivas criptográficas sin cambios arquitectónicos — es la respuesta correcta para sistemas nuevos, pero la mayoría de las organizaciones trabajan con sistemas construidos sin él. Adaptar la crypto-agility requiere el mismo trabajo de descubrimiento e inventario que la migración en sí.
Esquemas híbridos: el puente práctico
El IETF y las principales implementaciones de TLS han convergido en el intercambio de claves híbrido como estrategia de migración para TLS: combinar un algoritmo clásico (ECDH) con un algoritmo post-cuántico (ML-KEM) en un solo handshake, de modo que la sesión esté protegida mientras uno de los dos algoritmos sea seguro. Este enfoque protege tanto contra debilidades no descubiertas en los nuevos algoritmos post-cuánticos como contra ataques de cosechar ahora, descifrar después que usen computadoras cuánticas.
Google ha estado probando el intercambio de claves híbrido en Chrome desde 2023 usando una combinación de X25519 y ML-KEM-768, designada X25519MLKEM768. Cloudflare lo ha desplegado en toda su red perimetral. Las últimas versiones de BoringSSL, OpenSSL 3.x (a través del proveedor OQS) y LibreSSL admiten esquemas híbridos. Para TLS, el camino de migración es razonablemente claro y las herramientas están madurando rápidamente.
Para los esquemas de firma, la migración es más lenta porque los certificados deben ser reemitidos por AC de confianza. El CA/Browser Forum (CA/B Forum) está trabajando en estándares para certificados post-cuánticos, pero el despliegue masivo de certificados firmados con PQ probablemente esté a 3–5 años de contar con soporte amplio en los almacenes de confianza de navegadores y sistemas operativos.
Su marco de priorización de migración
No todo necesita migrar al mismo tiempo. Un enfoque basado en riesgos prioriza según dos dimensiones: qué tan sensible son los datos y cuánto tiempo deben permanecer confidenciales.
Comience con el intercambio de claves en TLS orientado al exterior: esta es la exposición más alta a HNDL, las herramientas están disponibles hoy y los esquemas híbridos significan que no necesita abandonar los algoritmos clásicos. Actualizar a una librería TLS con soporte para ML-KEM y habilitar el intercambio de claves híbrido en sus balanceadores de carga y API gateways es factible a corto plazo.
A continuación, haga un inventario de su PKI e infraestructura de certificados. Identifique todas las autoridades de certificación — internas y externas — y sus configuraciones de algoritmos. Planifique la complejidad operativa de ejecutar una PKI paralela (clásica y post-cuántica) durante el período de transición, ya que no todos los clientes admitirán certificados PQ de inmediato.
Evalúe su flota de HSM. La mayoría de los HSM fabricados antes de 2022 no admiten ML-KEM ni ML-DSA de forma nativa. Los proveedores de HSM, incluidos Thales, Entrust y Utimaco, han publicado hojas de ruta de PQC, pero los ciclos de reemplazo de hardware son largos y las aprobaciones presupuestarias son lentas. Inicie esas conversaciones de adquisición ahora.
Los secretos de larga duración son el objetivo de migración de mayor prioridad. Las claves de cifrado que protegen datos archivados, las claves privadas de la AC raíz, las credenciales VPN de largo plazo y las claves de firma de código que autentican software durante períodos de varios años necesitan protección resistente a cuánticos con urgencia. Las copias de seguridad cifradas con RSA de 2024 aún serán recuperables por un adversario cuántico en 2040.
Qué implementar este trimestre
Habilite el intercambio de claves híbrido en TLS para endpoints externos — tanto del lado del servidor (nginx, HAProxy, Cloudflare, AWS ALB) como del lado del cliente donde controle el stack TLS. Pruebe la compatibilidad con su base de clientes actual antes de implementar ampliamente. Realice un inventario de todos los activos criptográficos usando herramientas como Venafi o el motor de secretos PKI de HashiCorp Vault. Contacte a su proveedor de HSM sobre su cronograma de PQC. Evalúe si algún dato que cifre hoy tiene un requisito de confidencialidad que se extienda más allá de 2035. Informe a su CISO o liderazgo de seguridad con una evaluación de riesgos por escrito que cuantifique la exposición a HNDL — la mayoría de los presupuestos de seguridad responden más rápido a marcos de riesgo concretos que a argumentos abstractos sobre plazos.
La criptografía post-cuántica no es un problema que se resuelva esperando. Los estándares son definitivos, las herramientas existen para los casos de uso de mayor prioridad, y la amenaza de cosechar ahora, descifrar después es real y continua. Las organizaciones que comiencen su inventario de migración ahora tendrán años de margen para ejecutar metódicamente. Aquellas que esperen a que las computadoras cuánticas amenacen visiblemente los sistemas de producción estarán ejecutando bajo condiciones de emergencia.