¿Qué es el intercambio híbrido X25519+ML-KEM y por qué es el default de la transición?

Al 8 de noviembre de 2026, el intercambio de llaves por defecto de la transición post-cuántica es un híbrido: X25519MLKEM768, un grupo de TLS 1.3 que corre en paralelo, dentro del mismo handshake, el X25519 clásico y el ML-KEM-768 post-cuántico, y empalma ambos secretos en una sola llave. Es lo que Chrome despacha por defecto desde la versión 124 (abril de 2024, como X25519Kyber768; la forma final con ML-KEM llegó con Chrome 131 en noviembre de 2024), lo que Firefox 132 activó el 29 de octubre de 2024, y lo que OpenSSL 3.5.0 prefiere por defecto desde el 8 de abril de 2025. Rosetta Quantum mide lo que de verdad se despliega: el cliente envía 1.216 bytes de material de llave, el servidor responde con 1.120, y un atacante tiene que romper las dos cerraduras a la vez. El registro público sigue mostrando 0 llaves RSA-2048 rotas por computador cuántico y 0 brechas atribuidas a un ataque cuántico (re-verificado el 2026-11-08) — el híbrido es un seguro en ambas direcciones, no evidencia de un ataque en curso. Un dato medido más: la especificación que todos despliegan sigue siendo un Internet-Draft (draft-ietf-tls-ecdhe-mlkem-05, 26 de mayo de 2026), no un RFC. Nuestra pieza de presupuestos de bytes prometió que la mecánica de este handshake tendría su propia entrada; es esta.

¿Qué es exactamente X25519MLKEM768?

Es un único grupo nombrado de TLS 1.3 — code point IANA 4588 (0x11EC) — que ejecuta dos acuerdos de llave independientes dentro de un handshake: X25519, el Diffie-Hellman de curva elíptica en despliegue masivo en la web desde la década de 2010, y ML-KEM-768, el mecanismo de encapsulamiento de llaves basado en retículos que NIST estandarizó como FIPS 203 el 13 de agosto de 2024 (la familia completa está en nuestra pieza de estándares: ML-KEM, ML-DSA y SLH-DSA). Los dos secretos compartidos se concatenan — primero los 32 bytes de ML-KEM, después los 32 de X25519, un bloque de 64 bytes — y entran juntos al key schedule de TLS (draft-ietf-tls-ecdhe-mlkem-05, 26-may-2026). La llave de sesión queda segura mientras al menos uno de los dos componentes resista. Ese es todo el diseño: nada de matemática nueva — dos acuerdos de llave probados, soldados para que cada uno cubra el modo de falla del otro.

¿Cómo funciona el handshake híbrido, byte a byte?

En el mismo round trip de siempre — el costo es ancho, no latencia. El key_share del cliente para X25519MLKEM768 pesa 1.216 bytes: la llave de encapsulamiento de ML-KEM-768 (1.184 bytes) concatenada con la parte pública de X25519 (32 bytes). El servidor encapsula contra esa llave y responde con 1.120 bytes: el ciphertext de ML-KEM (1.088 bytes) más su propia parte X25519 de 32 bytes. Ambos lados derivan el mismo secreto concatenado de 64 bytes (todos los tamaños: draft-ietf-tls-ecdhe-mlkem-05, 26-may-2026). Compárelo con la línea base clásica que reemplaza: 32 bytes por lado. El híbrido multiplica los bytes del intercambio de llaves por ≈38 en el ClientHello — y en la práctica Chrome midió un aumento mediano de ≈1 KB y handshakes ≈4% más lentos al encender el híbrido, los números de despliegue que recorrimos en la pieza de presupuestos de bytes. Ese ClientHello agrandado fue también lo que rompió middleboxes defectuosos cuando Chrome 124 activó el default en abril de 2024 (BleepingComputer, 28-abr-2024): hardware que asumía que un hello cabe en un paquete cortaba la conexión. Ese episodio es la razón de que «¿su stack aguanta un key share de 1,2 KB?» sea hoy una pregunta real de compras.

¿Por qué híbrido, en vez de confiar solo en ML-KEM?

Porque la industria ya vio morir a un candidato post-cuántico en condiciones casi de producción — y la envoltura híbrida fue lo que convirtió eso en un no-evento. En octubre de 2019, Cloudflare y Google Chrome corrieron el TLS Post-Quantum Experiment: CECPQ2 (X25519 + NTRU-HRSS) y CECPQ2b (X25519 + SIKE) sobre conexiones reales (blog de Cloudflare, 30-oct-2019). En 2022, SIKE cayó por completo ante un ataque clásico en hardware común — la historia entera está en nuestra pieza de SIKE y Rainbow. Ninguna conexión CECPQ2b quedó expuesta, porque X25519 seguía debajo. Esa es la primera dirección del seguro: si la matemática nueva falla, la vieja sostiene. La segunda dirección es harvest-now-decrypt-later (nuestra pieza HNDL): el tráfico grabado hoy se volvería legible si un computador cuántico criptográficamente relevante llegara dentro de la vida útil del dato — una categoría de riesgo en tiempo futuro, no una práctica documentada de ningún actor con nombre. La mitad ML-KEM es la que importará contra esa máquina futura; X25519 solo, no. Para calibrar: la apuesta Q-Day de la casa — piso 2031, ventana 2033–2039 (RQ-PRED-QDAY-001) — es un juicio sellado y refutable, no una medición; el registro medido sigue en 0 llaves RSA rotas. El híbrido es además agilidad criptográfica practicada y no predicada: el mismo mecanismo que le permitió a Chrome cambiar el Kyber de borrador por el ML-KEM final en siete meses sin romper nada es el que permitiría sacar a ML-KEM.

¿Quién lo despliega hoy — y desde cuándo?

Todos los navegadores grandes, OpenSSL y la red de Cloudflare — más, fuera de TLS, dos mensajeros intensamente escrutados que usan el mismo patrón híbrido. El registro fechado:

Dos lecturas de esa tabla valen más que cualquier fila sola. Primera: el lado cliente de la web llegó sin pedirle permiso a nadie — si sus usuarios corren un navegador actual, la mayoría de su TLS entrante ya ofrece el híbrido; así fue como ≈70% del tráfico humano de una red grande llegó a negociar PQC en septiembre de 2026. Segunda: la columna de mensajería muestra la misma arquitectura elegida dos veces de forma independiente — Signal mezcla la salida ML-KEM-768 de SPQR con el Double Ratchet clásico para que un atacante tenga que romper ambos (signal.org, 2-oct-2025), y el PQ3 de Apple combina Kyber con criptografía de curva elíptica (The Hacker News, 22-feb-2024). Nadie que despliegue a escala confía en una sola cerradura.

¿Lo que todos despliegan ya es un estándar?

No — y es un hecho medido, algo incómodo, que vale decir sin vueltas: el intercambio de llaves por defecto de la transición post-cuántica está especificado por un Internet-Draft, no por un RFC. El documento — draft-ietf-tls-ecdhe-mlkem-05, con autores de PQShield, AWS, Cloudflare y la Universidad de Waterloo — es standards-track en el grupo de trabajo TLS del IETF, se publicó el 26 de mayo de 2026 y expirará el 27 de noviembre de 2026 salvo que antes aterrice una revisión o el RFC; lo re-verificaremos en su día. También deja formalmente obsoletos los code points pre-estándar de Kyber (25497, 25498) que usaron los despliegues tempranos de Chrome y Cloudflare. El borrador define tres grupos híbridos:

La letra chica con consecuencia presupuestaria: X25519 no es una curva aprobada por FIPS, así que las organizaciones obligadas a criptografía validada FIPS en las dos mitades del intercambio irán a SecP256r1MLKEM768 — 33 bytes más ancho por share de cliente, y mucho menos desplegado. Qué grupo negocian de verdad sus proveedores es una pregunta de una línea con respuesta verificable: el nombre del grupo y el code point aparecen en el handshake.

¿Qué hace un equipo de seguridad con esto?

Cuatro movimientos, en el orden que sugieren las mediciones. Primero, ubíquese en la asimetría: los navegadores ya ofrecen el híbrido, pero los escaneos de Cloudflare encontraron solo ≈15% de los servidores de origen soportando algún acuerdo de llave PQC al 29 de septiembre de 2026 — la brecha está casi con certeza en su lado servidor, CDN y balanceador, no en el de sus usuarios. Segundo, convierta «¿qué grupo nombrado, qué code point?» en pregunta fija a proveedores; la etiqueta «quantum-safe» no responde nada de lo que 4588 responde con precisión. Tercero, ponga los puntos de terminación TLS arriba del inventario criptográfico que el paso 1 de todos los reguladores ya pide (la pieza CBOM): el intercambio de llaves es la parte de la migración donde los estándares, los defaults y los despliegues medidos harán la mayor parte del trabajo por usted. Cuarto, calibre la urgencia con relojes regulatorios y no con pronósticos de Q-Day: NIST IR 8547, final desde el 27 de octubre de 2026, depreciará RSA y ECC después de 2030 y los prohibirá después de 2035 — fechas publicadas como política, no predicciones. Lo que NO va a hacer nada de este trabajo es el pánico: 0 llaves rotas, 0 brechas atribuidas, re-verificado hoy en el tablero de Rosetta.

Qué no sabemos

No sabemos cuándo aterrizará el RFC: el draft-05 expirará el 27 de noviembre de 2026 y no encontramos un sucesor publicado al cierre de esta pieza — si aparece una revisión o el RFC, será noticia y la fecharemos. No sabemos que ML-KEM sea irrompible: no existe un quiebre criptoanalítico público a hoy, y la ausencia de ataque no es una prueba — que es exactamente el argumento del respaldo X25519. No sabemos la adopción PQ más allá de las redes que publican mediciones: el par ≈70%/≈15% es el lente de Cloudflare (29-sep-2026), una red grande, no todo Internet. No sabemos el naming interno actual de Apple: PQ3 se anunció con «Kyber» en febrero de 2024, antes de que FIPS 203 fuera final, y nuestras fuentes son la cobertura de prensa y el análisis de Stebila de febrero de 2024, ambos anteriores al estándar final. Tampoco re-verificamos hoy desde una primaria el mes exacto de lanzamiento de PQXDH de Signal — nuestra secundaria lo fecha en 2023. Por último, el mapa jurisdicción por jurisdicción de qué sectores enfrentarán un plazo PQC vinculante (y cuáles solo guía) tendrá su propia pieza en esta serie.

Rosetta Quantum publica veredictos con datos crudos y reproducibles. Esto es contenido educativo — no es un claim de producto, no es asesoría de proveedores, no es asesoría de inversión.