FIPS 203: NIST estandariza ML-KEM y Chrome lo activa por defecto

Ninguna computadora cuántica existe hoy capaz de romper el cifrado que protege una compra online. Aun así, cuando abrís Chrome para entrar a un sitio detrás de Cloudflare, buena parte de esa conexión ya negocia una clave resistente a una computadora cuántica que todavía no se construyó. ML-KEM, el estándar que NIST publicó como FIPS 203 el 13 de agosto de 2024, quedó integrado por defecto en el navegador más usado del mundo y en una de las redes que sirve más tráfico HTTPS del planeta.

La migración no es un ejercicio académico. Gobiernos y empresas asumen que alguien puede estar grabando tráfico cifrado hoy para descifrarlo el día que exista una máquina cuántica suficientemente potente: la estrategia conocida como harvest now, decrypt later. Signal, Apple y ahora buena parte de la web abierta cierran ese punto ciego con un esquema híbrido, que combina el cifrado clásico de siempre con un algoritmo nuevo basado en retículos matemáticos.

TL;DR

• NIST publicó ML-KEM como el estándar FIPS 203 el 13 de agosto de 2024, basado en el algoritmo Kyber.- Google activó el grupo híbrido X25519Kyber768 en Chrome desde agosto de 2023 y luego lo migró a X25519MLKEM768.- Signal anunció PQXDH, su protocolo de acuerdo de claves poscuántico, el 19 de septiembre de 2023.- Apple integró PQ3 en iMessage a partir de iOS 17.4, lanzado en febrero de 2024.- OpenSSH ofrece intercambio de claves resistente a computadoras cuánticas por defecto desde la versión 9.0, de abril de 2022.- El esquema es híbrido: combina X25519 (clásico) con ML-KEM-768 (poscuántico), así que hay que romper los dos a la vez.- La amenaza que motiva la migración se llama harvest now, decrypt later: grabar tráfico cifrado hoy para descifrarlo después.

Qué pasó

Google fue el primero en mover una pieza grande del tablero. En agosto de 2023 Chrome empezó a ofrecer un grupo híbrido llamado X25519Kyber768 en las conexiones TLS 1.3, usando la versión de Kyber que todavía era un borrador del proceso de estandarización. Cuando NIST cerró el estándar final en agosto de 2024, el algoritmo cambió de nombre a ML-KEM y el grupo TLS pasó a llamarse X25519MLKEM768. Ese cambio de nombre no es cosmético: el proceso de estandarización introdujo ajustes en la codificación de parámetros respecto al Kyber original, así que un cliente con el Kyber de 2023 y un servidor con el ML-KEM final no son compatibles entre sí sin actualizar.

Cloudflare siguió el mismo camino en su borde de red, y hoy documenta en vivo qué porción del tráfico que atiende ya negocia un grupo poscuántico en Cloudflare Radar. Como Chrome concentra la mayoría del tráfico de navegación mundial y activa X25519MLKEM768 por defecto, cualquier servidor que hable TLS 1.3 y ofrezca ese grupo termina usándolo sin que el usuario haga nada.
NIST tardó ocho años, desde la convocatoria de 2016 hasta el estándar FIPS 203 en 2024.

Contexto e historia

La razón de fondo es un algoritmo de 1994. Peter Shor demostró que una computadora cuántica suficientemente grande puede factorizar números enteros y calcular logaritmos discretos en tiempo eficiente, justo los dos problemas matemáticos sobre los que se sostienen RSA y la criptografía de curva elíptica (incluido X25519). Mientras esa máquina no exista a escala útil, RSA y ECC siguen siendo seguros hoy. El riesgo es el tráfico grabado ahora y descifrado después.

NIST abrió una convocatoria pública en 2016 para reemplazar esos algoritmos por otros que resistan tanto a computadoras clásicas como cuánticas. Tras varias rondas de eliminación por criptoanálisis público, en julio de 2022 seleccionó CRYSTALS-Kyber para intercambio de claves y CRYSTALS-Dilithium, FALCON y SPHINCS+ para firmas digitales. Kyber se basa en el problema Module-LWE sobre retículos: encontrar un vector corto en una red de puntos de muchas dimensiones, un problema para el que no se conoce un algoritmo cuántico eficiente como el de Shor.

Detalles técnicos y rendimiento de ML-KEM

Cómo funciona el intercambio híbrido

En un handshake TLS 1.3 con X25519MLKEM768, el navegador no manda una sola clave pública: manda dos, una de X25519 y una de ML-KEM-768, concatenadas en el mismo mensaje ClientHello. El servidor responde con su propia clave X25519 y el ciphertext de ML-KEM, y ambos lados combinan los dos secretos resultantes con una función de derivación de claves (KDF) para obtener el secreto de sesión final.

sequenceDiagram
    participant N as Navegador
    participant S as Servidor
    N->>S: ClientHello con clave X25519 y clave publica ML-KEM-768
    S-->>N: ServerHello con ciphertext ML-KEM y clave publica X25519
    Note over N,S: ambos derivan el mismo secreto combinando los dos algoritmos

Ese diseño híbrido es deliberado. Si mañana aparece un fallo matemático en los retículos y ML-KEM cae, la conexión sigue protegida por X25519. Si en cambio aparece la computadora cuántica y rompe X25519, la conexión sigue protegida por ML-KEM. Un atacante necesita romper los dos algoritmos a la vez, no solo uno.

El costo: claves más grandes

Nada de esto es gratis. Una clave pública de X25519 pesa 32 bytes. La de ML-KEM-768, el nivel de seguridad que usan Chrome y Cloudflare, ronda los 1.184 bytes según la especificación de FIPS 203, casi 37 veces más grande. El ciphertext que el servidor devuelve mide otros 1.088 bytes. En un handshake TLS 1.3 normal eso no agrega una vuelta de red extra (la clave sigue viajando en el primer y segundo mensaje del handshake), pero sí infla el tamaño de esos paquetes, algo que pesa más en enlaces de baja capacidad o en dispositivos embebidos con memoria RAM limitada para guardar el estado del handshake.
OpciónCuándo usarlaVentajaLimitaciónX25519 (clásico)Conexiones donde el riesgo cuántico a largo plazo no es una prioridadClaves de 32 bytes, muy rápidoVulnerable a harvest now, decrypt later si aparece una computadora cuánticaML-KEM-768 puroEntornos que exigen resistencia cuántica total, sin depender de ECCSeguro frente al algoritmo de ShorMenos historial de análisis público que ECC; un fallo en el retículo lo rompe todoX25519MLKEM768 (híbrido)Estándar recomendado hoy en TLS 1.3, el que usan Chrome y CloudflareHay que romper ambos algoritmos a la vezMensajes de handshake más pesados que con un solo algoritmo

💭 Clave: El objetivo de ML-KEM no es protegerte de una computadora cuántica que exista hoy: es evitar que el tráfico que alguien grabe ahora se pueda descifrar dentro de diez o quince años.
La clave pública de ML-KEM-768 pesa unas 37 veces más que la de X25519.

Cómo probarlo

Confirmar si una conexión ya negocia un grupo poscuántico toma un comando. Con una build de OpenSSL 3.2 o superior (o el proveedor oqs-provider si tu OpenSSL no lo trae de fábrica), podés forzar el grupo y leer qué respondió el servidor:

openssl s_client -connect www.cloudflare.com:443 -tls1_3 -groups X25519MLKEM768 /dev/null | grep "Negotiated TLS1.3 group"

Si el servidor lo soporta, la salida muestra Negotiated TLS1.3 group: X25519MLKEM768. Para revisar del lado de un servidor propio con nginx sobre OpenSSL 3.2+, alcanza con declarar el grupo en la configuración TLS:

ssl_protocols TLSv1.3;
ssl_conf_command Groups X25519MLKEM768:X25519;

Con esa línea, nginx ofrece el grupo híbrido primero y cae a X25519 puro si el cliente no lo soporta. Para el otro extremo del stack, el de SSH, alcanza con listar los algoritmos de intercambio de claves que tu build de OpenSSH 9.9 o superior soporta:

ssh -Q kex | grep -i mlkem

Si aparece mlkem768x25519-sha256 en la lista, tus conexiones SSH salientes ya pueden negociar el mismo tipo de esquema híbrido que usa la web.

Impacto y análisis

El intercambio de claves es la parte fácil de migrar: cambia en cada conexión nueva y no depende de una cadena de confianza previa. Las firmas digitales son harina de otro costal. Un certificado TLS today firma con RSA o ECDSA, y migrar eso a un algoritmo poscuántico como Dilithium implica cambiar toda la cadena de confianza (autoridad certificadora, cliente, servidor) al mismo tiempo, con certificados mucho más pesados que los actuales. Por eso Chrome, Cloudflare, Signal y Apple empezaron por el intercambio de claves: es la pieza que más urgencia tiene (por el riesgo de grabar tráfico hoy) y la que menos fricción de compatibilidad genera.

La limitación real es esa asimetría. Hoy tu tráfico HTTPS puede viajar con una clave de sesión resistente a computadoras cuánticas, pero el certificado que identifica al servidor sigue firmado con un algoritmo que Shor rompería si existiera la máquina adecuada. Eso no compromete la confidencialidad retroactiva (el objetivo de ML-KEM), pero sí deja abierta la puerta a que, en un futuro cuántico, alguien pueda falsificar la identidad de un servidor. La migración de firmas viene después, y es la parte más lenta y costosa del proceso.

Qué sigue

NIST ya publicó también los estándares para firmas poscuánticas: FIPS 204 (ML-DSA, derivado de Dilithium) y FIPS 205 (SLH-DSA, derivado de SPHINCS+), ambos el mismo 13 de agosto de 2024 junto con FIPS 203. La adopción de esos dos va a tardar más porque toca a las autoridades certificadoras, al ecosistema de navegadores y a cada cliente que valida certificados. Mientras tanto, es probable que el intercambio de claves híbrido se vuelva el default en más protocolos además de TLS y SSH: VPNs, mensajería empresarial y cualquier canal donde grabar tráfico hoy tenga valor dentro de una década.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré openssl s_client -connect www.cloudflare.com:443 -groups X25519MLKEM768 contra cualquier sitio detrás de Cloudflare y mirá si tu conexión ya negocia el grupo híbrido.

Preguntas frecuentes

¿Qué es ML-KEM y en qué se diferencia de Kyber?

ML-KEM es el nombre final que le dio NIST al algoritmo Kyber cuando lo estandarizó como FIPS 203 en agosto de 2024. El diseño matemático es el mismo (un mecanismo de encapsulado de claves basado en retículos), pero el estándar final ajustó detalles de codificación respecto a las versiones de Kyber que circulaban como borrador.

¿Por qué usar un esquema híbrido en vez de solo poscuántico?

Porque ML-KEM es un algoritmo relativamente nuevo, con menos años de criptoanálisis público que X25519. Combinar ambos significa que un atacante tiene que romper los dos a la vez, así que un fallo futuro en cualquiera de los dos algoritmos no compromete la conexión por sí solo.

¿Mi conexión ya está protegida contra computadoras cuánticas?

Si usás una versión reciente de Chrome contra un servidor que soporte X25519MLKEM768 (como los que están detrás de Cloudflare), sí, al menos en el intercambio de claves. El certificado del servidor, en cambio, todavía suele estar firmado con un algoritmo clásico.

¿Qué es harvest now, decrypt later?

Es la estrategia de grabar tráfico cifrado hoy, aunque no se pueda descifrar todavía, para guardarlo y descifrarlo el día que exista una computadora cuántica capaz de romper RSA o ECC. Es la amenaza concreta que justifica migrar el cifrado ahora, no cuando esa máquina exista.

¿Cuándo se van a actualizar los certificados y firmas digitales a poscuánticos?

NIST ya publicó los estándares de firma (FIPS 204 y FIPS 205) el mismo día que ML-KEM, pero migrar certificados exige coordinar autoridades certificadoras, navegadores y clientes a la vez, así que ese proceso avanza más lento que el del intercambio de claves.

¿Necesito hacer algo como desarrollador?

Si administrás un servidor con OpenSSL 3.2+ o una versión reciente de nginx, alcanza con habilitar el grupo X25519MLKEM768 en la configuración TLS. Para SSH, con actualizar a OpenSSH 9.9 o superior ya tenés el intercambio híbrido disponible.

Referencias

• NIST FIPS 203: el estándar oficial de ML-KEM, publicado el 13 de agosto de 2024.- Signal, anuncio de PQXDH: el protocolo de acuerdo de claves poscuántico de Signal, del 19 de septiembre de 2023.- Apple Security, PQ3 para iMessage: detalle técnico del esquema híbrido que Apple integró desde iOS 17.4.- Blog de Chromium: anuncio del soporte híbrido con Kyber en Chrome, agosto de 2023.- Cloudflare Radar: datos en vivo sobre adopción de cifrado poscuántico en el tráfico que gestiona Cloudflare.- Notas de lanzamiento de OpenSSH: historial de versiones, incluida la 9.0 con intercambio de claves poscuántico por defecto.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.