X25519MLKEM768 o X25519: intercambio poscuántico en TLS

X25519MLKEM768 frente a X25519 es la decisión de intercambio de claves que se toma hoy en cada handshake TLS 1.3. X25519 por sí solo es rápido y diminuto, pero cae ante una computadora cuántica, lo que significa que el tráfico grabado ahora podría descifrarse más adelante. X25519MLKEM768 ejecuta X25519 y ML-KEM-768 a la vez, de modo que la sesión sigue siendo confidencial salvo que se rompan ambos.

De un vistazo

Rendimiento medido con openssl speed en un núcleo de un Apple M4 Max; los tamaños del handshake proceden de la captura de más abajo.

Por qué el híbrido ahora

El intercambio de claves está expuesto a «cosechar ahora, descifrar después» (harvest now, decrypt later): un adversario graba hoy sesiones cifradas y las descifra cuando exista una computadora cuántica criptográficamente relevante; entonces recupera las claves de sesión a partir del intercambio X25519 grabado. El forward secrecy no ayuda, porque cada intercambio grabado se puede romper por separado. Todo aquello cuya confidencialidad deba durar más allá de la llegada de esa computadora ya está en riesgo, y por eso el intercambio de claves se adelantó, mientras que las firmas pueden esperar más.

El diseño híbrido también cubre el riesgo contrario. ML-KEM se estandarizó en agosto de 2024 y es joven en comparación con X25519, así que una ruptura matemática o de implementación no es impensable. X25519MLKEM768 concatena ambos secretos compartidos en el key schedule de TLS (la fase que deriva las claves a partir del secreto compartido), de modo que un atacante tiene que romper los dos. En este grupo, el RFC 10024 coloca primero el key share y el secreto de ML-KEM, a diferencia de los híbridos con curvas NIST (SecP256r1MLKEM768, 0x11EB, y SecP384r1MLKEM1024, 0x11ED), que ponen ECDH primero.

Qué cambia en la red

El cliente envía un key share de 1216 bytes en lugar de 32 bytes, así que un ClientHello típico crece de unos 300 bytes a unos 1,5 KB y ya no cabe en un solo paquete de red junto con todas las demás extensiones de un navegador. El servidor responde con un key share de 1120 bytes. Un handshake real con Cloudflare, capturado con OpenSSL 3.6.5, muestra la diferencia:

echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519MLKEM768 -brief 2>&1 | grep -E "Protocol|group"
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519MLKEM768 -msg 2>&1 | grep -E "ClientHello|ServerHello"
echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -groups X25519 -msg 2>&1 | grep -E "ClientHello|ServerHello"

Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768
>>> TLS 1.3, Handshake [length 05cc], ClientHello
<<< TLS 1.3, Handshake [length 04ba], ServerHello
>>> TLS 1.3, Handshake [length 0132], ClientHello
<<< TLS 1.3, Handshake [length 007a], ServerHello

Son 1484 frente a 306 bytes en el ClientHello y 1210 frente a 122 en el ServerHello. Los ClientHello más grandes sacaron a la luz errores en servidores y dispositivos intermedios que daban por hecho que el mensaje llega en una sola lectura TCP o en un solo paquete; cuando Chrome activó por defecto los key shares híbridos de Kyber en la versión 124 (2024), hubo que corregir varios productos de cortafuegos y de proxy, un tipo de problema documentado en tldr.fail. Cloudflare y Google informaron de que los bytes adicionales aumentan la latencia mediana del handshake en un pequeño porcentaje, algo que importa mucho menos que los viajes de ida y vuelta que ahorra el propio TLS 1.3.

Estado del despliegue

• Navegadores: Chrome y Edge ofrecen X25519MLKEM768 por defecto desde la versión 131 (noviembre de 2024), Firefox desde la 132 en escritorio, y Safari y el TLS del sistema de Apple desde iOS 26 y macOS 26 (2025). El grupo previo al estándar X25519Kyber768Draft00 (0x6399), que usaban antes, está en desuso.
• Bibliotecas: OpenSSL 3.5 (abril de 2025) envía por defecto key shares de X25519MLKEM768 y de X25519; Go 1.24 lo activa por defecto en crypto/tls; JDK 27 (septiembre de 2026, JEP 527) lo ofrece en primer lugar por defecto; BoringSSL, rustls y NSS lo admiten.
• Servidores y CDN: Cloudflare, Google y otros grandes proveedores lo negocian con los clientes que lo admiten; nginx, Apache y HAProxy lo obtienen de la versión de OpenSSL con la que están enlazados.
• SSH: el equivalente mlkem768x25519-sha256 es el predeterminado de OpenSSH desde la versión 10.0 (RFC 10042).

La comprobación de TLS poscuántico del navegador muestra qué negocia tu propio navegador.

Cuándo elegir cada uno

• HTTPS y API públicos: ofrece X25519MLKEM768 en primer lugar y X25519 en segundo; todos los clientes modernos negocian el híbrido y los antiguos recurren a X25519.
• Malla de servicios interna y mTLS: híbrido por defecto, sobre todo para datos con requisitos de confidencialidad a largo plazo.
• Despliegues orientados a FIPS: SecP256r1MLKEM768 o SecP384r1MLKEM1024 si la lista de algoritmos aprobados de tu módulo exige curvas NIST; X25519MLKEM768 cumple los requisitos allí donde ML-KEM es el componente aprobado.
• Enlaces limitados en los que cada paquete cuenta: mide primero; el híbrido añade un paquete en cada sentido, lo que suele ser aceptable.
• X25519 por sí solo: solo para los extremos que no pueden usar el híbrido, nunca como elección deliberada en despliegues nuevos.

Notas de migración

1. Actualiza la biblioteca TLS (OpenSSL 3.5 o posterior, Go 1.24 o posterior, versiones actuales de BoringSSL o rustls); con OpenSSL 3.5, los grupos predeterminados ya incluyen el híbrido.
2. Si defines los grupos de forma explícita, añádelo: por ejemplo, ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; en nginx o Groups = X25519MLKEM768:X25519:P-256 en un archivo de configuración de OpenSSL.
3. Prueba toda la ruta, no solo el servidor: los balanceadores de carga, los WAF y los proxies que inspeccionan TLS deben gestionar un ClientHello repartido entre varios paquetes y lecturas; vuelve a probarlos después de cada actualización.
4. Verifica qué se negocia con openssl s_client -groups X25519MLKEM768 o con las herramientas para desarrolladores del navegador, y supervisa la proporción de handshakes híbridos.
5. Planifica por separado el lado de las firmas: el híbrido solo protege la confidencialidad; los certificados y las firmas del handshake siguen siendo clásicos hasta que las firmas poscuánticas lleguen a la WebPKI.

Referencias

• RFC 10024, mecanismos híbridos PQ/T de acuerdo de claves para TLS 1.3
• RFC 9954, intercambio de claves híbrido en TLS 1.3
• FIPS 203, ML-KEM
• RFC 7748, X25519
• Registro de grupos admitidos de TLS (TLS Supported Groups) de la IANA
• Notas de la versión de OpenSSL 3.5
• tldr.fail: errores de fragmentación del ClientHello
• NIST IR 8547 ipd §4.1.2 (establecimiento de claves)