Migración poscuántica en 2026: plan para desarrolladores

Respuesta breve. En 2026, buena parte del trabajo poscuántico para el cifrado en tránsito se resuelve actualizando. Chrome, Firefox, las versiones 26 de Apple, OpenSSL 3.5, Go 1.24+, JDK 27 y OpenSSH 10 negocian por defecto un intercambio de claves híbrido con ML-KEM. Tu trabajo es encontrar las conexiones que todavía no lo hacen: bibliotecas antiguas, listas de grupos fijadas, dispositivos intermedios (middleboxes), TLS 1.2, VPN, servicios internos. Las firmas y los certificados son la parte lenta. Las CA públicas todavía no pueden emitir certificados ML-DSA para navegadores, así que haz el inventario ahora, pon en marcha un piloto con ML-DSA en tu PKI privada y diseña pensando en la agilidad de algoritmos. Las fechas de planificación son las del borrador IR 8547 de NIST: las claves de 112 bits, como RSA-2048, quedan obsoletas después de 2030, y todos los algoritmos de clave pública vulnerables a la computación cuántica, prohibidos después de 2035. CNSA 2.0, de la NSA, fija fechas anteriores para los sistemas de seguridad nacional de EE. UU.

Dos problemas, dos relojes

Una computadora cuántica criptográficamente relevante rompería RSA, Diffie-Hellman de campo finito y la criptografía de curva elíptica (ECDH, ECDSA, EdDSA) con el algoritmo de Shor. La criptografía simétrica y los hashes sobreviven con los tamaños de clave actuales: AES-256 y SHA-256 o superiores. Nadie puede decirte cuándo existirá una máquina así. La página del proyecto OpenSSH sitúa las estimaciones publicadas en «entre 5 y 20 años, y muchos observadores esperan que lleguen a mediados de la década de 2030». La migración se divide en dos problemas de urgencia muy distinta:

• Confidencialidad, que es urgente. El tráfico cifrado que se graba hoy puede descifrarse en cuanto exista la computadora cuántica. Es lo que se conoce como «cosechar ahora, descifrar después» (harvest now, decrypt later). Todo lo que deba seguir siendo secreto durante más de unos pocos años ya está expuesto si su intercambio de claves es clásico. La solución es el intercambio de claves poscuántico, y se puede desplegar hoy.
• Autenticación, que tiene un plazo. Una firma falsificada solo importa cuando alguien confía en ella, así que la computadora cuántica tiene que existir en ese momento. Pero las claves de firma y las anclas de confianza viven mucho tiempo. Los certificados raíz, las claves de firmware, las claves de firma de código y los documentos firmados archivados se consideran de confianza durante décadas, y reemplazarlos lleva años.

Planifica el trabajo en ese orden: primero el intercambio de claves, después las firmas.

Los plazos que existen de verdad

Tres cosas que conviene tener en cuenta sobre esta tabla:

1. IR 8547 sigue siendo un borrador. Las agencias y los proveedores planifican en torno a las fechas de 2030 y 2035, pero todavía no son política definitiva de NIST. En el borrador, «obsoleto» (deprecated) significa que todavía puedes usar el algoritmo si aceptas el riesgo, y «prohibido» (disallowed) significa que no puedes usarlo en absoluto.
2. El paso de 2030 afecta a las claves de 112 bits, sobre todo a RSA-2048. RSA-2048 sigue presente en muchos certificados y en muchos firmantes de tokens (dos de los seis endpoints del escaneo de más abajo lo usan). P-256 y RSA-3072 son de 128 bits y siguen valiendo hasta 2035, pero pasarse a ellos te da cinco años como mucho, porque el borrador prohíbe todo lo vulnerable a la computación cuántica después de 2035.
3. La nota al pie de CNSA 2.0 importa para los híbridos. Los modos híbridos están permitidos, pero los algoritmos de CNSA 2.0 «serán de selección obligatoria en la fecha indicada», así que una configuración solo clásica deja de ser aceptable.

Lo que ya es poscuántico por defecto

Estos componentes negocian un intercambio de claves híbrido con ML-KEM sin ninguna configuración, si los dos extremos son lo bastante recientes:

En el lado del servidor también hay avances. Un escaneo con OpenSSL 3.5.7 el 20 de octubre de 2026, con el script de la sección de inventario, dio este resultado:

www.cloudflare.com:443     TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
github.com:443             TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA256
www.google.com:443         TLSv1.3  X25519MLKEM768    id-ecPublicKey 256 bit    ecdsa-with-SHA256
login.microsoftonline.com:443 TLSv1.3  ECDH,secp384r1    rsaEncryption 2048 bit    sha256WithRSAEncryption
api.stripe.com:443         TLSv1.3  X25519,253bits    rsaEncryption 2048 bit    sha256WithRSAEncryption
letsencrypt.org:443        TLSv1.3  X25519,253bits    id-ecPublicKey 256 bit    ecdsa-with-SHA384

Dos columnas lo resumen todo. El intercambio de claves es desigual: algunos servicios tienen el híbrido y otros no. Las columnas del certificado son clásicas sin excepción: ECDSA P-256 o RSA-2048. Lo mismo ocurre con SSH, donde GitHub ya elige el híbrido para un cliente OpenSSH 10:

debug1: kex: algorithm: mlkem768x25519-sha256

Paso 1: inventario

No puedes migrar lo que no puedes enumerar. Un inventario criptográfico útil responde, para cada uso de la criptografía de clave pública: qué algoritmo y qué tamaño de clave, qué biblioteca y qué versión, quién controla la configuración, cuánto tiempo deben seguir siendo confidenciales los datos protegidos y durante cuánto tiempo hay que poder confiar en la clave o la firma.

Empieza por lo que puedes medir desde fuera, tus endpoints TLS:

#!/bin/bash
for target in "$@"; do
  host=${target%:*}; port=${target##*:}; [ "$host" = "$target" ] && port=443
  out=$(openssl s_client -connect "$host:$port" -servername "$host" -brief </dev/null 2>&1)
  proto=$(grep -m1 "^Protocol version" <<<"$out" | cut -d: -f2 | xargs)
  group=$(grep -m1 "^Negotiated TLS1.3 group" <<<"$out" | cut -d: -f2 | xargs)
  [ -z "$group" ] && group=$(grep -m1 "^Peer Temp Key" <<<"$out" | cut -d: -f2 | cut -d, -f1-2 | tr -d ' ')
  cert=$(openssl s_client -connect "$host:$port" -servername "$host" </dev/null 2>/dev/null | openssl x509 -noout -text 2>/dev/null)
  key=$(grep -m1 "Public Key Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  bits=$(grep -m1 -o -E "\([0-9]+ bit\)" <<<"$cert" | tr -d '()')
  sig=$(grep -m1 "Signature Algorithm" <<<"$cert" | cut -d: -f2 | xargs)
  printf '%-26s %-8s %-17s %-25s %s\n' "$host:$port" "$proto" "$group" "$key $bits" "$sig"
done

Tiene que ejecutarse con un cliente OpenSSL 3.5, porque los clientes más antiguos nunca ofrecen el híbrido y para ellos todos los servidores parecen clásicos. Para muchos dominios a la vez, el comprobador masivo de dominios muestra por cada host el intercambio de claves, los algoritmos del certificado y la caducidad.

Después pasa al interior, donde está la mayor parte del trabajo:

• Bibliotecas y entornos de ejecución. Enumera las versiones de OpenSSL, BoringSSL, Go, JDK, .NET, Node.js y Python de cada imagen y de cada host. OpenSSL 3.0 ya no tiene soporte del proyecto original ni incluye ML-KEM, y Ubuntu 24.04 todavía lo distribuye. Ese único dato explica muchos resultados.
• Configuración explícita. Busca listas de grupos y de algoritmos de cifrado como ssl_ecdh_curve, SSLOpenSSLConfCmd Groups, CurvePreferences, jdk.tls.namedGroups y KexAlgorithms. Cada una es un punto al que no llegará una actualización de los valores predeterminados.
• Código. Busca usos directos de las API de RSA, ECDSA, ECDH y Ed25519, tamaños de clave, valores alg de JWT y claves públicas almacenadas en bases de datos. Las firmas almacenadas en formatos de datos son lo más difícil de cambiar más adelante.
• Claves y certificados de larga vida. Raíces de CA privadas, claves de firma de código y de firmware, firma de documentos, CA de SSH, claves guardadas en HSM. Anota la fecha de caducidad de cada una y los algoritmos que admite el HSM.
• Proveedores. Balanceadores de carga, WAF, proxies que inspeccionan TLS, concentradores VPN, bases de datos gestionadas, API SaaS. Pide a cada proveedor por escrito su hoja de ruta para ML-KEM y ML-DSA.

Registra el resultado en un formato legible por máquina. CycloneDX añadió una lista de materiales criptográficos (CBOM, Cryptography Bill of Materials) justo para esto. Describe algoritmos, claves, certificados y protocolos como componentes de tu inventario de software, junto al SBOM de paquetes que quizá ya generes.

Paso 2: completar el intercambio de claves

Para cada punto de terminación TLS que controles:

1. Actualiza la biblioteca TLS. OpenSSL 3.5, Go 1.24 o posterior, JDK 27, o una compilación actual de BoringSSL o AWS-LC.
2. Elimina las listas de grupos fijadas, o pon X25519MLKEM768 en primer lugar. Una línea de refuerzo de seguridad copiada de una guía antigua es la razón más habitual de que un servidor moderno negocie X25519 a secas. La mecánica se explica en X25519MLKEM768 explicado.
3. Prueba a través de la ruta de red real. El ClientHello híbrido ocupa unos 1,5 KB. Algunos cortafuegos, balanceadores de carga y proxies que inspeccionan TLS fallan con ClientHellos que ocupan dos paquetes. Compara un handshake híbrido y uno solo clásico por la misma ruta antes de culpar al servidor.
4. Comprueba los dos tramos. Detrás de una CDN o un balanceador de carga, la conexión entre el borde (edge) y el origen es una sesión TLS independiente. El tráfico grabado en ese tramo puede cosecharse exactamente igual.
5. Retira TLS 1.2 donde puedas. Los grupos híbridos solo están definidos para TLS 1.3.

Después, los canales que no son web:

• SSH. OpenSSH 9.0 y posteriores ya negocian un híbrido poscuántico cuando ambos extremos lo admiten. Los servidores antiguos, los dispositivos de red y las pilas SSH embebidas a menudo no. Los clientes de OpenSSH 10.1 y posteriores muestran una advertencia que nombra el riesgo: «This session may be vulnerable to 'store now, decrypt later' attacks.»
• VPN e IPsec. IKEv2 admite intercambios de claves adicionales (RFC 9370), que los proveedores usan para añadir ML-KEM. Consulta las notas del firmware de tu pasarela.
• Cifrado a nivel de aplicación. Todo lo que envuelve claves de datos con RSA o ECDH, como el cifrado de sobre, las copias de seguridad cifradas o la mensajería de extremo a extremo, necesita una vía con ML-KEM o con un KEM híbrido. HPKE (RFC 9180) con un KEM híbrido es el componente básico habitual. El laboratorio de HPKE muestra cómo encajan las piezas.

Paso 3: firmas y certificados

Aquí el ecosistema no está preparado para hacerlo por ti, así que en 2026 el trabajo consiste en prepararse:

• Certificados web públicos: espera, pero prepárate. Ningún navegador acepta certificados ML-DSA de CA públicas. Chrome dijo en febrero de 2026 que no tiene ningún plan inmediato para añadir a su almacén raíz certificados X.509 con claves poscuánticas. Está construyendo un almacén raíz independiente y resistente a la computación cuántica en torno a los Merkle Tree Certificates, que se están estandarizando en el grupo de trabajo PLANTS del IETF. Hasta que eso llegue, el trabajo útil es la automatización. Un equipo que puede rotar cualquier certificado en minutos cambiará de algoritmo con facilidad, y la menor vida útil de los certificados empuja en la misma dirección.
• PKI privada: haz ya un piloto con ML-DSA. El mTLS interno, las mallas de servicios, la identidad de los dispositivos y los certificados de VPN están bajo tu control en ambos extremos. OpenSSL 3.5, Go 1.27, Java 24+, .NET 10 y BouncyCastle manejan claves y certificados ML-DSA. Cuenta con un certificado hoja de unos 5,5 KB con ML-DSA-65 y prueba qué se rompe: tamaños de búfer, límites de encabezados, compatibilidad del HSM. ML-DSA para desarrolladores tiene código que funciona y los problemas habituales con los formatos de clave.
• Primero, las anclas de confianza de larga vida. Una clave raíz o de firmware creada en 2026 seguirá siendo de confianza después de 2035. Para firmar actualizaciones de firmware y software, CNSA 2.0 exige los esquemas basados en hash con estado LMS o XMSS (SP 800-208) y espera su uso exclusivo para 2030. SLH-DSA, sin estado (FIPS 205), es la alternativa conservadora cuando no puedes gestionar el estado de las firmas.
• Artefactos firmados que deben seguir siendo verificables. Los documentos, los archivos y los registros firmados hoy con ECDSA tienen que volver a protegerse antes de que sus firmas dejen de ser fiables. Planifica la renovación de los sellos de tiempo y la nueva firma de los archivos, como ya hace la validación a largo plazo de los PDF con los certificados que caducan.
• Tokens y API. JOSE y COSE tienen identificadores registrados para ML-DSA (RFC 9964). Una firma de 3,3 KB hace que un JWT ocupe unos 4,5 KB en base64url, lo que importa para las cookies y los encabezados. Mide antes de cambiar.

Paso 4: abaratar el próximo cambio

La migración no será un único cambio. Más adelante, el intercambio de claves híbrido puede dar paso a ML-KEM puro. A ML-DSA puede sumarse FN-DSA, que NIST prevé publicar como FIPS 206. Las firmas compuestas e híbridas todavía se están diseñando. La agilidad criptográfica es lo que evita que cada uno de esos cambios se convierta en otro proyecto de varios años:

• Los identificadores de algoritmo viajan con los datos (un OID, un alg de JOSE, un byte de versión), y los verificadores deciden según ellos en lugar de dar nada por supuesto.
• Los tamaños de clave y de firma no están fijados en el código. Las columnas, los búferes y los campos de protocolo tienen espacio para kilobytes.
• Las claves se generan, se almacenan y se rotan de forma automatizada. Nadie copia a mano un archivo PEM en una configuración.
• La configuración está en un solo lugar por cada stack, de modo que el próximo cambio de grupo o de algoritmo es una sola edición.

Errores frecuentes

• Probar con un cliente antiguo. openssl s_client de OpenSSL 3.0, o curl enlazado con él, nunca ofrece el híbrido. Entonces todos los servidores parecen clásicos, incluso los que ya están migrados.
• Tomar el borde de la CDN por la conexión completa. El tramo del navegador al borde suele ser poscuántico, mientras que el tramo del borde al origen de la misma solicitud no lo es.
• Desactivar el híbrido para arreglar un dispositivo intermedio defectuoso. Eso elimina la protección de todas las conexiones. Arregla o sustituye el dispositivo.
• Esperar a los certificados ML-DSA públicos antes de hacer nada. El inventario, las actualizaciones de bibliotecas y la automatización de certificados hacen falta de todos modos, y llevan más tiempo que la espera.
• Tratar «obsoleto después de 2030» como «permitido hasta 2035». Los datos que cifres en 2029 con un intercambio de claves clásico quedan expuestos durante todo el tiempo que deban seguir siendo confidenciales. Los plazos son para el cumplimiento normativo, no para la seguridad.

Lista de comprobación para lo que queda de 2026

1. Ejecuta un escaneo con OpenSSL 3.5 de cada endpoint TLS público e interno, y registra el grupo, el algoritmo del certificado y la versión de la biblioteca.
2. Actualiza las bibliotecas TLS de las imágenes base. Elimina las listas de grupos fijadas. Vuelve a escanear.
3. Prueba el híbrido a través de cada dispositivo intermedio de la ruta, incluido el tramo del borde al origen.
4. Actualiza los servidores SSH a OpenSSH 9.9 o posterior para tener ML-KEM (9.0 y posteriores ya ofrecen el híbrido sntrup761), y los dispositivos de red para los que exista firmware.
5. Enumera todas las claves de firma y anclas de confianza de larga vida con su caducidad y los algoritmos que admite su HSM.
6. Monta una CA de pruebas con ML-DSA y emite certificados para un servicio interno.
7. Automatiza la emisión y la rotación de certificados en todos los sitios donde todavía sean manuales.
8. Pide a tus proveedores, por escrito, las fechas de compatibilidad con ML-KEM y ML-DSA.

Fuentes

• NIST IR 8547 ipd, Transición a los estándares de criptografía poscuántica (noviembre de 2024), tablas 2–4.
• NSA, Anuncio de la Commercial National Security Algorithm Suite 2.0 (CSA PP-22-1338, septiembre de 2022): algoritmos y calendario de transición.
• Hoja de ruta coordinada para la transición a la criptografía poscuántica, grupo de trabajo de PQC de la UE, versión 1.1, 11 de junio de 2025.
• NCSC, Plazos para la migración a la criptografía poscuántica (marzo de 2025).
• FIPS 203, FIPS 204, FIPS 205, SP 800-208.
• OpenSSH, Criptografía poscuántica, y las notas de versión de OpenSSH 9.0, 9.9, 10.0 y 10.1.
• Estrategia de versiones de OpenSSL (3.5 LTS hasta 2030-04-08). Notas de versión de Go 1.24, JEP 527.
• Google Security Blog, Cómo cultivar un HTTPS robusto, eficiente y resistente a la computación cuántica (febrero de 2026).

Los escaneos se ejecutaron el 20 de octubre de 2026 desde node:24.22.0-trixie (OpenSSL 3.5.7, OpenSSH 10.0p2).