SSH y TLS post-cuánticos

La criptografía post-cuántica pasó una década siendo tema de congreso y después, sin ruido, se convirtió en el valor por defecto de tu portátil. Si usas OpenSSH 10 y un navegador de los últimos dos años, buena parte de tu tráfico ya está protegido frente a un adversario cuántico y nadie te avisó. Lo que queda por hacer es estrecho, poco lucido y muy concreto: encontrar las conexiones que se quedaron atrás. Esto es una guía para hacerlo sobre infraestructura real: qué comprobar, qué cambiar, cómo verificarlo después y qué parte del problema conviene no tocar todavía.

El marco que hace manejable todo esto es una separación. La criptografía protege tus conexiones de dos formas: el acuerdo de claves, que decide el secreto que cifra la sesión, y las firmas, que demuestran con quién estás hablando. Un ordenador cuántico rompe las dos. Pero solo una es urgente hoy, y confundirlas es la razón por la que tantos programas post-cuánticos acaban encallados en una hoja de cálculo. Todo lo que sigue se deduce de esa distinción.

Dónde está realmente la criptografía post-cuántica en 2026

El acuerdo de claves está hecho. No planificado ni en piloto: publicado, activado por defecto y funcionando. OpenSSH ofrece acuerdo de claves post-cuántico desde la versión 9.0, en abril de 2022, y desde OpenSSH 10.0, en abril de 2025, el híbrido mlkem768x25519-sha256 es el algoritmo por defecto. OpenSSL 3.5.0, publicado un día antes, cambió su lista de grupos TLS por defecto para incluir y preferir grupos híbridos post-cuánticos, y ahora ofrece X25519MLKEM768 como keyshare por defecto. Si actualizaste cualquiera de los dos paquetes en el último año, activaste esto sin hacer nada.^{[ssh100][ossl35]}

Las mediciones acompañan. Cloudflare publica cifras de adopción del acuerdo de claves post-cuántico desde 2023, y la curva pasó de ser un error de redondeo a la mayoría del tráfico web humano en unos dos años. Consulta el dato en vivo en lugar de fiarte de ningún artículo, incluido este: lo relevante no es el porcentaje exacto sino la forma de la curva, que es lo que te dice que los rezagados ya son un conjunto finito y enumerable en vez de internet entero.^{[cfpq][cfradar]}

Con las firmas ocurre justo lo contrario. NIST estandarizó ML-DSA y SLH-DSA en 2024, hay implementaciones, y nada de eso es desplegable en la web pública, porque un certificado solo sirve si la parte que lo valida ya confía en la raíz que lo firmó, y no hay ninguna raíz post-cuántica en los almacenes de confianza de los navegadores. Esto no es un problema temporal de empaquetado que puedas sortear con ingenio: es un problema de secuencia del ecosistema, y va para años.

Cosecha ahora, descifra después: y lo que ese ataque no cubre

La razón de que el acuerdo de claves sea urgente y las firmas no se reduce a una asimetría, y OpenSSH la explica con más claridad que la mayoría del material comercial:^[pq]

Toda la privacidad de una conexión SSH depende del acuerdo criptográfico de claves. Si un atacante consigue romperlo, puede descifrar y ver la sesión completa. No necesita realizar el ataque en tiempo real: puede recopilar sesiones SSH cifradas ahora y descifrarlas más adelante, cuando tenga acceso a un ordenador cuántico.^[pq]

Eso es cosecha ahora, descifra después, y es un ataque retroactivo. Una sesión capturada hoy en el cable, con un intercambio clásico, es un pasivo permanente: se queda en un archivo hasta que exista un ordenador cuántico criptográficamente relevante, y entonces se abre. Nada de lo que hagas en 2032 arregla una sesión grabada en 2026. Las firmas no tienen equivalente, porque falsificar una firma a posteriori no te permite volver atrás y suplantar a alguien en una conversación que ya ocurrió. Eso te da una regla de priorización limpia:

• Datos confidenciales de vida larga sobre un enlace de vida larga. Replicación de bases de datos por WAN, transferencias de copias de seguridad, túneles VPN entre sedes, sesiones SSH donde pegas credenciales. Arregla esto primero: la carga útil conserva su valor una década o más.
• Tráfico que cruza un camino no confiable. Todo lo que sale de tu red y, en un modelo de amenaza serio, todo lo que cruza el backbone de un proveedor cloud. Capturar es barato para quien tiene posición; almacenar, más barato aún.
• Enlaces máquina a máquina donde nadie inicia sesión. Son los que se le escapan a la auditoría, porque no hay un humano que vea el aviso. Mallas de servicios, colas de mensajes, canales de replicación, agentes de monitorización.
• Tráfico interno, efímero y de bajo valor. Un health check entre dos pods del mismo nodo no merece un ticket de migración. Escríbelo, para que la excepción sea una decisión y no un descuido.

Las estimaciones sobre cuándo llegará un ordenador cuántico criptográficamente relevante van de cinco a veinte años, y bastantes observadores apuntan a mediados de la década de 2030. No necesitas tener opinión sobre esa cifra. Necesitas saber si los datos que transmites hoy siguen siendo sensibles cuando llegue, y para casi toda la infraestructura la respuesta honesta es que sí.^[pq]

Arreglar SSH

SSH es la victoria fácil y el sitio correcto por donde empezar, porque OpenSSH ya ha hecho la parte difícil. No hay plugin, ni proveedor que instalar, ni rama experimental. Hay un número de versión y una línea de configuración, y el proyecto publica ambos.^{[ssh100][pq][ssh105][sshrel]}

En esa tabla se esconden dos trampas. La primera es el nombre: la forma corta sntrup761x25519-sha512 solo existe desde la 9.9, así que en versiones anteriores hay que escribir la variante @openssh.com, y sshd se niega a arrancar ante un nombre que no reconoce. La segunda es más insidiosa. Estar en la lista por defecto no es lo mismo que ser elegido: en OpenSSH 8.9 el algoritmo post-cuántico viene en el KexAlgorithms por defecto pero en sexta posición, por debajo de curve25519-sha256, de modo que cualquier cliente moderno negocia un intercambio clásico contra él mientras el servidor informa con toda verdad de que soporta post-cuántico. Esa es exactamente la razón por la que este artículo insiste en leer el resultado negociado y no la lista de capacidades.^{[ssh85][ssh99][ntru]}

Paso 1: averigua qué estás negociando de verdad

Antes de cambiar nada, mide. La distinción con la que tropieza casi todo el mundo es entre soportado y negociado: un servidor puede soportar ML-KEM y aun así completar un intercambio clásico, porque un cliente viejo lo pidió y la lista de preferencias del servidor lo permitía. Solo el algoritmo negociado te dice si una conexión concreta estuvo realmente protegida.

# 1. Your client. Anything older than 8.5 has no post-quantum key agreement
#    at all; 8.5 through 9.8 have it only under the @openssh.com vendor name.
ssh -V
# OpenSSH_10.5p1, OpenSSL 3.5.7 9 Jun 2026

# 2. The remote server's software version, straight from the protocol banner.
ssh -v server.example.com exit 2>&1 | grep 'remote software version'
# debug1: Remote protocol version 2.0, remote software version OpenSSH_10.3

# 3. Which key agreement algorithms your local build even supports.
ssh -Q kex | grep -E 'mlkem|sntrup'
# mlkem768x25519-sha256
# sntrup761x25519-sha512

# 4. Supported is not preferred. On OpenSSH 8.9, for example, the PQ algorithm
#    is in the default list but sixth in it, so it is offered and never chosen:
ssh -G server.example.com | grep -i '^kexalgorithms'
# kexalgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,
# ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,...
#                                       ^ present, but nothing will ever pick it

# 5. The only answer that matters: what did THIS connection actually agree on?
#    Everything above is capability; this line is the negotiated result.
ssh -v server.example.com exit 2>&1 | sed -n 's/.*kex: algorithm: /negotiated: /p'
# negotiated: mlkem768x25519-sha256

Cuando sabes leer esa línea en un host, sabes leerla en todos. OpenSSH 10.1 añadió un aviso en el cliente cuando la conexión negocia un intercambio no post-cuántico, algo excelente para humanos e inútil para los enlaces automáticos que forman la mayor parte de una flota real. Así que barre tú:^[ssh101]

#!/usr/bin/env bash
# pq-ssh-sweep.sh - classify every host in hosts.txt by negotiated key agreement.
# Read-only: it opens a connection, runs `exit`, and reads the debug output.
set -uo pipefail

while read -r host; do
  [ -z "$host" ] && continue
  # </dev/null matters: without it ssh swallows the rest of hosts.txt from the
  # loop's stdin and you silently audit only the first host.
  alg=$(ssh -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=accept-new \
        -v "$host" exit </dev/null 2>&1 | sed -n 's/.*kex: algorithm: //p' | head -1)
  case "$alg" in
    mlkem*)   printf '%-38s PQ-ML-KEM  %s\n' "$host" "$alg" ;;
    sntrup*)  printf '%-38s PQ-LEGACY  %s\n' "$host" "$alg" ;;
    "")       printf '%-38s UNREACHED  (auth, firewall or timeout)\n' "$host" ;;
    *)        printf '%-38s CLASSICAL  %s\n' "$host" "$alg" ;;
  esac
done < hosts.txt

# PQ-ML-KEM  -> done, nothing to do.
# PQ-LEGACY  -> safe today (sntrup761 is quantum-resistant) but not the NIST
#               standard; schedule the upgrade to OpenSSH 9.9+ anyway.
# CLASSICAL  -> this is your harvest-now-decrypt-later exposure. Fix first.

Paso 2: cambia la configuración, con cuidado

Con el sondeo delante, el cambio en sí es pequeño. Ponlo en un fichero drop-in en lugar de editar la configuración principal, para que quede localizable, reversible y evidentemente tuyo:^{[sshdcfg][ssh99]}

# /etc/ssh/sshd_config.d/50-post-quantum.conf
# Requires `Include /etc/ssh/sshd_config.d/*.conf` in the main sshd_config,
# which Debian, Ubuntu, RHEL and Fedora already ship. Check with:
#   grep -r '^Include' /etc/ssh/sshd_config

# --- OpenSSH 9.9 and newer ---
# Post-quantum first, classical last. The list is ordered by preference, and
# the two hybrids are the only entries here that resist a quantum adversary.
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256,curve25519-sha256@libssh.org

# --- OpenSSH 9.0 to 9.8: NEITHER name above exists on those builds. ---
# ML-KEM only arrived in 9.9, and until 9.9 the NTRU Prime hybrid existed
# solely under its vendor extension name. sshd refuses to start on an
# unknown algorithm name, so on those versions use exactly this line and
# nothing from the one above:
#   KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
# Confirm which names your build accepts before editing:  ssh -Q kex

# Signatures are NOT the urgent problem (see the article), but this is a good
# moment to drop the algorithms that are weak for classical reasons too.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,rsa-sha2-512,rsa-sha2-256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# --- Validate BEFORE reloading, and keep your current session open. ---
#   sudo sshd -t && sudo systemctl reload ssh   # or sshd, depending on the distro
# Then open a SECOND session and confirm it works before closing the first.

No te saltes el ritual de validación. Ejecuta sshd -t antes de recargar, mantén abierta la sesión actual y abre una segunda sesión para confirmar antes de cerrar la primera. Una errata en KexAlgorithms te deja fuera del host, y en una máquina sin acceso a consola eso no es una incidencia: es una reinstalación.

El lado cliente es donde puedes permitirte ser más estricto, porque fallar ruidosamente en tu propio portátil es asumible de un modo que no lo es en un bastión compartido. El patrón que sobrevive al contacto con la realidad es un valor por defecto duro más excepciones explícitas y fechadas:^[sshcfg]

# ~/.ssh/config - client side
#
# ssh_config is FIRST-OBTAINED-VALUE-WINS, not last. The specific block must
# come BEFORE `Host *`, otherwise the general block wins and the exception
# below is silently dead. This is the single most common mistake in hardened
# client configs, and it fails in the direction you will not notice.

# Exceptions first: the boxes you have not fixed yet. Make each one explicit
# and dated, so it shows up in review instead of quietly becoming permanent.
Host legacy-nas.internal jump-2019.example.com
    # TODO(2026-11-30): appliance firmware pending, ticket OPS-4471
    # Note this REPLACES the list rather than using `+`, which would append to
    # the full compiled-in default and quietly re-enable every modp group.
    KexAlgorithms curve25519-sha256,diffie-hellman-group-exchange-sha256
    WarnWeakCrypto no-pq-kex

# ...and the hard default for everything else.
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512
    WarnWeakCrypto yes

# Verify the result rather than trusting the file. `ssh -G` prints the
# effective configuration for a given destination, after all matching:
#   ssh -G legacy-nas.internal | grep -i '^kexalgorithms'
#   ssh -G anything-else.example.com | grep -i '^kexalgorithms'

Dos detalles que conviene interiorizar. Primero, todos los algoritmos post-cuánticos que implementa OpenSSH son híbridos: mlkem768x25519-sha256 ejecuta ML-KEM junto a X25519 y combina ambos, de modo que si el criptoanálisis futuro rompe ML-KEM el resultado no es más débil que el intercambio clásico que usabas antes. No hay escenario en el que salgas perdiendo. Segundo, si estás en OpenSSH 9.x y no puedes actualizar, el híbrido NTRU Prime es resistente a cuántica y existe desde la 9.0, pero ojo al nombre: antes de la 9.9 solo está disponible como sntrup761x25519-sha512@openssh.com, y la forma corta será rechazada. No es el algoritmo de NIST, pero detiene el ataque de cosecha hoy, que es de lo que se trata.^[pq]

Arreglar TLS

TLS tiene la misma forma con otra palanca. Las primitivas viven en OpenSSL, no en tu servidor web: con OpenSSL 3.5 o superior no necesitas parches, ni oqs-provider, ni un nginx bifurcado. Comprueba primero la biblioteca, porque ahí se esconden casi todas las sorpresas: una distribución puede empaquetar un nginx actual enlazado contra un OpenSSL que no sabe hacer ML-KEM en absoluto.^{[ossl35][tlsdraft][mlkemkex]}

# 1. ML-KEM needs OpenSSL 3.5.0 or newer. No 3.x before 3.5 can do it at all,
#    however recent the rest of the stack looks.
openssl version
# OpenSSL 3.5.7 9 Jun 2026

# 2. Confirm the provider actually exposes the primitives.
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -iE 'ML-DSA|SLH-DSA'

# 3. What does a live endpoint negotiate when the client offers the hybrid?
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null \
  | grep -E 'Negotiated TLS1.3 group|Protocol  :|Cipher    :'
# Negotiated TLS1.3 group: X25519MLKEM768

# 4. Control test: the same endpoint must still serve a classical-only client,
#    otherwise you have not hardened it, you have broken it.
openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 -tls1_3 </dev/null 2>/dev/null \
  | grep 'Negotiated TLS1.3 group'
# Negotiated TLS1.3 group: X25519

Fíjate en la prueba de control del paso cuatro. Activar un grupo híbrido no debe romper a los clientes clásicos, y si los rompe es que has configurado mal la lista, no que hayas endurecido nada. El orden importa; la exclusividad no: pon el híbrido delante y deja las curvas clásicas detrás.^[osslgroups]

# Pick the ONE stanza that matches your terminator - this is four different
# config syntaxes in one block, not a file you can paste as-is.

### nginx (built against OpenSSL 3.5+; no patches, no oqs-provider needed)
# ssl_ecdh_curve feeds the TLS supported-groups list. Hybrid first, then the
# classical curves that keep older clients working.
ssl_protocols       TLSv1.3 TLSv1.2;
ssl_ecdh_curve      X25519MLKEM768:X25519:secp256r1;
ssl_prefer_server_ciphers off;

### HAProxy 3.x
ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1

### Apache httpd (mod_ssl passes the list straight to OpenSSL)
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

### OpenSSL system-wide default, for everything that reads openssl.cnf
# [openssl_init] -> ssl_conf -> system_default
Groups = X25519MLKEM768:X25519:secp256r1

La configuración es una línea por servidor y, en todos los casos, alimenta la misma lista de grupos soportados de OpenSSL:^{[nginxssl][haproxy][osslconf]}

Lo único arquitectónicamente importante: esto solo aplica donde TLS se termina. Si un CDN o un balanceador termina por ti, ese es el salto que necesita el grupo híbrido, y la configuración de tu origen es una pregunta aparte, igual que el enlace entre ambos, que es justo el tramo interno que se olvida. Si terminas en Kubernetes, esto pertenece al gateway, y la migración desde ingress-nginx es un momento natural para hacerlo, ya que vas a reescribir esos objetos de todos modos.^[rfc8446]

Un inventario que puedas defender

Todo lo anterior es por host. Lo que te van a pedir los auditores, y tu yo futuro, es cobertura: no «¿está arreglado este endpoint?» sino «¿cuántos hay y cuáles no lo están?». Construye la lista desde la fuente de verdad en la que ya confías, no desde un escaneo, para que la ausencia signifique algo:

#!/usr/bin/env bash
# pq-inventory.sh - a starting point, not a CBOM. One line per listener, with
# the negotiated group, so the output diffs cleanly between runs.
set -uo pipefail
printf '%-34s %-9s %-22s %s\n' HOST PORT GROUP NOTE

while IFS=: read -r host port; do
  out=$(openssl s_client -connect "$host:$port" -servername "$host" \
        -groups X25519MLKEM768:X25519 -tls1_3 </dev/null 2>/dev/null)
  grp=$(printf '%s' "$out" | sed -n 's/^Negotiated TLS1.3 group: //p')
  sig=$(printf '%s' "$out" | sed -n 's/^Peer signature type: //p')
  case "$grp" in
    *MLKEM*) note="pq-ok" ;;
    "")      note="no-tls1.3-or-unreachable" ;;
    *)       note="classical-only" ;;
  esac
  printf '%-34s %-9s %-22s %s (sig %s)\n' "$host" "$port" "${grp:--}" "$note" "${sig:--}"
done < endpoints.txt

# endpoints.txt is one host:port per line. Feed it from whatever you already
# trust as the source of truth - the load balancer config, Consul, the CMDB -
# rather than from a network scan, so that absence is meaningful.

Resiste la tentación de comprar un producto de inventario criptográfico antes de haber ejecutado algo así. Las herramientas están mejorando de verdad, pero la primera pasada merece hacerse a mano porque te enseña la forma de tu propio parque, que es justo lo que ningún proveedor puede darte. Orden de trabajo:

1. Terminación TLS externa. Todos los nombres públicos. La lista más corta, la exposición más alta, y normalmente se arregla con un cambio en el borde.
2. SSH, en todas partes. Primero los bastiones, después todo lo alcanzable desde ellos. Aquí es donde aflora la cola larga de appliances, electrónica de red y máquinas virtuales olvidadas.
3. TLS interno entre servicios. Malla de servicios, conexiones a bases de datos, brokers de mensajería. Lista más larga, más difícil de enumerar, y el sitio donde los propios valores por defecto de la malla puede que ya lo hayan resuelto.
4. VPN y túneles site-to-site. De vida larga, alto valor y con frecuencia sobre firmware de fabricante con su propio calendario. Empieza pronto la conversación con el proveedor, porque esto es más un problema de compras que técnico.
5. Todo lo empotrado. Dispositivos, agentes, impresoras, cámaras, controladores industriales. Documéntalos, acepta el riesgo explícitamente y ponle fecha a esa aceptación.

Mantén la salida comparable y vuelve a ejecutarla de forma periódica. Un número que se mueve en la dirección equivocada es la señal más temprana de que una imagen reconstruida o un paquete revertido han deshecho el trabajo en silencio, y ese fallo es mucho más frecuente que una migración mal hecha.

Firmas y certificados: por qué conviene esperar

Ahora la parte donde el consejo útil es hacer menos. NIST estandarizó en 2024 dos esquemas de firma post-cuánticos, ML-DSA y SLH-DSA, y ambos están implementados en OpenSSL 3.5. Puedes generar las claves hoy. No deberías meterlas en tu cadena de certificados.^{[fips204][fips205][fips203]}

El motivo es el mismo que da OpenSSH al explicar por qué priorizó el acuerdo de claves: no existe un ataque de «almacenar ahora, falsificar después». Una firma solo tiene que ser infalsificable en el momento en que se verifica. La urgencia con las firmas no consiste en proteger el tráfico de hoy, sino en asegurarse de que las claves de firma clásicas se retiren antes de que exista un ordenador cuántico criptográficamente relevante: un plazo que se mide en años, no en paquetes capturados.^[pq]

Los bloqueos prácticos tienen forma de ecosistema y ninguno te toca resolverlo a ti:

• Los navegadores no confían en ninguna raíz post-cuántica. Una cadena de certificados vale lo que valga la raíz en la que la contraparte ya confía, y esos almacenes se mueven con un ritmo de varios años por buenas razones.
• El problema de tamaño es real. Las firmas y claves públicas de ML-DSA son bastante mayores que las de ECDSA. En un handshake que transporta la cadena completa, eso se mide en viajes de ida y vuelta adicionales sobre enlaces con pérdidas, no en bytes abstractos.
• OpenSSH solo tiene un esquema de firma post-cuántico experimental. El proyecto eliminó su soporte experimental de XMSS en la 10.1 y después añadió en la 10.4 (julio de 2026) un esquema compuesto mldsa44-ed25519 que combina ML-DSA-44 con Ed25519. Es explícitamente experimental y no está activado por defecto: tienes que añadirlo tú a HostKeyAlgorithms y PubkeyAcceptedAlgorithms y generar las claves con ssh-keygen -t mldsa44-ed25519. Conviene conocerlo; todavía no conviene ponerlo bajo las claves de host de producción.^{[ssh104][mldsased][ssh101]}
• Todos los intermedios tienen que estar de acuerdo. La validación de certificados implica a tu servidor, al cliente, a cada middlebox que inspecciona y a cualquier pinning que alguien añadió en 2019. Las firmas fallan en cerrado, y fallan para todos a la vez.

¿Qué hacer entonces con las firmas en 2026? Dos cosas, ambas baratas. Retirar los algoritmos que ya son débiles por motivos clásicos: DSA desapareció por completo en OpenSSH 10.0, y las firmas SHA-1 deberían haberse ido hace años. Y hacer que la emisión de certificados sea automática y de vida corta, para que cuando los certificados post-cuánticos sean emitibles, cambiarlos sea un ajuste de configuración y no un proyecto. La cripto-agilidad no es un producto que se compra: es la propiedad de poder rotar rápido, que deberías querer por razones completamente ajenas a esto. Aquí aplica el mismo instinto que hay detrás de las arquitecturas aburridas: la opción exótica no es la segura.^[ssh103]

El calendario normativo, contado con precisión

Los plazos son donde los artículos técnicos se vuelven incorrectos sin darse cuenta, así que aquí va la versión cuidadosa. NIST IR 8547, el documento que todo el mundo cita para «RSA queda obsoleto en 2030», es un borrador público inicial publicado en noviembre de 2024. Su periodo de comentarios cerró en enero de 2025 y los comentarios recibidos son públicos. Señala el enfoque previsto por NIST y es la entrada correcta para planificar, pero citarlo como un estándar final y vinculante es inexacto, y alguien en tu revisión lo sabrá.^[ir8547]

La distinción importa en la práctica: un borrador te dice hacia dónde se mueve el suelo, lo cual basta para planificar. No basta para escribir «exigido por NIST» en un documento de diseño. Cítalo como el borrador que es y tu programa sobrevivirá a su primera revisión seria.^[ir8547]

Europa va por una vía paralela con mecánica distinta. Los Estados miembros adoptaron una hoja de ruta coordinada de implementación a través del Grupo de Cooperación NIS, estructurada en torno a iniciar la transición y ejecutar pilotos antes de finales de 2026, completar los casos de uso de alto riesgo y las infraestructuras críticas para 2030, y terminar en la medida de lo practicable para 2035. Es un instrumento de coordinación más que un reglamento, pero es aquello contra lo que se están escribiendo las hojas de ruta nacionales, así que si operas en la UE es el documento que ha leído tu supervisor sectorial.^[euroadmap]

Una consecuencia que conviene nombrar para quien opera en varias jurisdicciones: estos calendarios convergen en las mismas fechas finales pero no en las mismas obligaciones, y el firmware de fabricante es la restricción vinculante en todos ellos. Si un dispositivo tiene un ciclo de reemplazo de cinco años, la compra que hagas este año es una decisión post-cuántica lo diga o no alguien en el hilo de compras.

Un plan de 90 días

Si quieres todo esto en una página, aquí está. La premisa es que el acuerdo de claves es un problema resuelto que simplemente estás desplegando, y todo lo demás es preparación.

Noventa días es realista para las tres primeras fases en la mayoría de parques, porque los cambios son pequeños y el riesgo se concentra en el sondeo más que en la edición. Lo que siempre tarda más son las mismas dos cosas: appliances que no puedes actualizar y enlaces que nadie sabía que existían. Ambas aparecen en la primera semana si haces el inventario bien, que es el argumento para hacerlo primero.

Cinco errores que salen caros

Patrones que se repiten en migraciones reales, ordenados aproximadamente por el tiempo que cuestan:

1. Auditar capacidad en lugar de negociación. «Nuestros servidores soportan ML-KEM» no es un hallazgo. Un servidor puede soportarlo y aun así completar handshakes clásicos todo el día por un cliente viejo. Lee el algoritmo negociado en la conexión, no la lista de soportados.
2. Eliminar los algoritmos clásicos. Los híbridos existen precisamente para no tener que elegir. Pon el grupo post-cuántico delante, deja X25519 detrás y ganas protección sin una incidencia de disponibilidad.
3. Perseguir certificados. El tiempo dedicado a intentar desplegar certificados ML-DSA en 2026 es tiempo que no dedicas al intercambio que sí se está cosechando. Automatiza la emisión: ese es el trabajo que rinde después.
4. Pararse en el borde. El handshake del CDN es post-cuántico y el enlace al origen no. Es el hueco más habitual con diferencia, porque la prueba externa pasa y el tramo interno no tiene usuario que se queje.
5. Tratarlo como algo puntual. Una imagen base reconstruida, un paquete fijado, una configuración revertida, y un host que cumplía en marzo negocia en clásico en septiembre. Pon el barrido en un temporizador — un timer de systemd sobra — y alerta cuando el recuento suba.

La versión corta

El acuerdo de claves post-cuántico no es un proyecto futuro. Es un valor por defecto que probablemente ya has heredado, y todo el trabajo consiste en encontrar las conexiones que se lo saltaron. Actualiza a OpenSSH 10.x y OpenSSL 3.5+, pon el grupo híbrido en primer lugar en ambos, barre la flota buscando lo que se negocia de verdad y escribe las excepciones con fecha. Para la mayoría de equipos es una semana de trabajo y cierra el único ataque de este ámbito que está ocurriendo hoy.

Y después, para. No migres certificados, no compres una plataforma de cripto-agilidad y no escribas «cuántico» en un documento de estrategia. Haz que la emisión de certificados sea automática y de vida corta, mantén el inventario al día y espera al ecosistema, porque cuando las firmas post-cuánticas sean desplegables, las organizaciones que lo lleven bien no serán las que empezaron antes: serán las que ya pueden rotar un certificado sin ventana de cambio.

Preguntas frecuentes

¿Tengo que hacer algo si ya estoy en OpenSSH 10?

Verificar y, probablemente, nada más. El valor por defecto es mlkem768x25519-sha256, pero una línea base de hardening, una plantilla derivada de CIS o un módulo de gestión de configuración puede haber escrito su propio KexAlgorithms anterior a ML-KEM que lo excluye en silencio. Ejecuta ssh -v host exit 2>&1 | grep 'kex: algorithm' contra un host real y lee el resultado negociado. Para las sesiones entrantes, lo que manda es el lado servidor.

¿Activar el intercambio post-cuántico rompe los clientes antiguos?

No, si lo configuras como preferencia y no como restricción. Tanto KexAlgorithms en SSH como la lista de grupos soportados en TLS son preferencias ordenadas: pon el híbrido delante y deja curve25519-sha256 o X25519 detrás, y los pares modernos obtendrán el intercambio post-cuántico mientras los antiguos caen al clásico. Las roturas llegan cuando eliminas por completo las entradas clásicas, que es una decisión defendible en una flota cerrada bajo tu control y mala para cualquier cosa pública.

¿sntrup761x25519-sha512 es suficiente o hay que pasar a ML-KEM?

Es realmente resistente a cuántica y detiene hoy el ataque de cosechar ahora y descifrar después, que es la propiedad que necesitas. Su debilidad es de estandarización, no criptográfica: NTRU Prime no fue seleccionado por NIST, así que no satisfará un régimen de cumplimiento escrito alrededor de FIPS 203, y el soporte de implementación a largo plazo es menos seguro. Si estás en OpenSSH 9.0–9.8 y no puedes actualizar este trimestre, estás protegido. Planifica igualmente el salto a 9.9+.

¿Por qué no puedo desplegar ya certificados post-cuánticos?

Porque un certificado solo sirve si la parte que lo valida ya confía en la raíz que lo firmó, y no hay ninguna raíz post-cuántica en los almacenes de confianza de los navegadores. Puedes generar claves ML-DSA con OpenSSL 3.5 y montar con ellas una CA interna, lo cual es un experimento razonable para un sistema cerrado. Para cualquier cosa que toque un navegador, la cadena no validará. Es un problema de secuencia del ecosistema, no de configuración, y se resuelve en años.

¿Cómo compruebo qué negocia realmente mi endpoint TLS?

openssl s_client -connect host:443 -servername host -groups X25519MLKEM768 -tls1_3 </dev/null 2>/dev/null | grep 'Negotiated TLS1.3 group'. Necesitas un cliente OpenSSL 3.5+ para la propia prueba: probar con un cliente más antiguo produce un falso negativo, porque tu cliente nunca ofreció el grupo. Ejecuta siempre también la prueba de control con -groups X25519, para confirmar que has endurecido el endpoint y no que lo has roto.

¿Debo preocuparme por AES y SHA-256?

No. El algoritmo de Grover ofrece una aceleración cuadrática frente a primitivas simétricas, lo que en la práctica reduce a la mitad la longitud de clave: AES-256 conserva un margen de seguridad de 128 bits y SHA-256 sigue siendo adecuado. AES-128 se discute más, pero no es la preocupación práctica. Los algoritmos asimétricos —RSA, ECDH, ECDSA— son los que rompe de raíz el algoritmo de Shor, y son todo el asunto de este artículo.

¿Y las VPN, las bases de datos y las colas de mensajes?

Misma regla, ejecución más difícil. WireGuard no tiene acuerdo de claves post-cuántico en su protocolo base y se apoya en su mecanismo de clave precompartida para montar un esquema híbrido. El soporte de IPsec depende por completo del firmware de tu fabricante. El TLS de bases de datos y brokers suele seguir la pila TLS del propio runtime en lugar del OpenSSL del sistema, así que verifica cada uno por separado en vez de suponer que un ajuste global llegó hasta ahí. Además, estos enlaces son los objetivos de más valor, porque la carga útil es exactamente el dato confidencial de vida larga que el ataque de cosecha busca recoger.

¿Esto es teatro de cumplimiento o una amenaza real?

La amenaza es real pero está desplazada en el tiempo, y por eso es fácil calibrarla mal en ambos sentidos. Nadie está descifrando tu tráfico hoy. La pregunta es si el tráfico capturado hoy sigue siendo sensible a mediados de la década de 2030 y, para historiales médicos, datos financieros, material legal, comunicaciones gubernamentales y credenciales de vida larga, la respuesta es claramente que sí. Lo peculiar de este riesgo concreto es que la mitigación es casi gratis —una subida de versión y una línea de configuración—, así que el cálculo coste-beneficio no te obliga a creer en ninguna fecha de llegada en particular.

Todo esto da por hecho que el sistema base no se mueve, y sí se mueve: actualizar Ubuntu 24.04 a 26.04 en servidores repasa la actualización de versión que te cambia seis de estos valores por defecto.

Fuentes

Todas las fuentes de abajo se leyeron al escribir este artículo. Se citan notas de versión de los proyectos y documentos de normalización con preferencia sobre coberturas secundarias y, cuando un documento es un borrador y no un estándar final, se describe como tal.

1. OpenSSH — Post-Quantum Cryptography (project page, FAQ and warning text)
2. OpenSSH 9.9 release notes (19 September 2024) — ML-KEM hybrid added; sntrup761x25519-sha512 gains its IANA name
3. OpenSSH 10.0 release notes (9 April 2025) — mlkem768x25519-sha256 becomes the default key agreement
4. OpenSSH 10.1 release notes (6 October 2025) — warning on non-post-quantum key agreement, WarnWeakCrypto
5. OpenSSH 8.5 release notes (3 March 2021) — sntrup761x25519-sha512@openssh.com replaces the older NTRU Prime hybrid, disabled by default
6. OpenSSH 10.3 release notes (2 April 2026)
7. OpenSSH 10.4 release notes (6 July 2026) — experimental mldsa44-ed25519 composite post-quantum signature scheme, not enabled by default
8. OpenSSH 10.5 release notes (11 August 2026) — current release at the time of writing
9. OpenSSH — full release notes index
10. ssh_config(5) — KexAlgorithms, WarnWeakCrypto, Match
11. sshd_config(5) — KexAlgorithms, HostKeyAlgorithms, Include
12. IETF draft-ietf-sshm-mlkem-hybrid-kex — hybrid ML-KEM key exchange for SSH
13. IETF draft-ietf-sshm-ntruprime-ssh — sntrup761x25519-sha512 for SSH (successor to the expired draft-josefsson document)
14. IETF draft-miller-sshm-mldsa44-ed25519-composite-sigs — the composite signature scheme OpenSSH 10.4 implements
15. OpenSSL 3.5 series release notes — PQC support and hybrid groups preferred by default (3.5.0, 8 April 2025)
16. OpenSSL documentation — SSL_CTX_set1_groups_list(3), the TLS supported-groups list
17. OpenSSL documentation — SSL_CONF_cmd(3), the Groups command Apache passes through
18. nginx documentation — ssl_ecdh_curve in ngx_http_ssl_module
19. HAProxy configuration manual — ssl-default-bind-curves
20. IETF draft-ietf-tls-ecdhe-mlkem — hybrid ECDHE + ML-KEM groups for TLS 1.3
21. RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
22. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
23. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA)
24. NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA)
25. NIST IR 8547 (Initial Public Draft, 12 November 2024) — Transition to Post-Quantum Cryptography Standards
26. European Commission / NIS Cooperation Group — Coordinated Implementation Roadmap for the Transition to PQC
27. Cloudflare — State of the post-quantum Internet in 2025
28. Cloudflare Radar — post-quantum encryption adoption (live figures)