El key share del cliente es la clave de encapsulación ML-KEM-768 de 1184 bytes seguida de una clave pública X25519 de 32 bytes (1216 bytes); el servidor responde con el texto cifrado ML-KEM de 1088 bytes más su clave X25519 de 32 bytes (1120 bytes). El secreto compartido es el secreto ML-KEM de 32 bytes seguido del secreto X25519 de 32 bytes. Algo poco habitual: aquí la parte poscuántica va primero, mientras que en SecP256r1MLKEM768 y SecP384r1MLKEM1024 va primero la parte ECDH.
Sustituyó al X25519Kyber768Draft00 (0x6399), anterior al estándar, que usaba Kyber de la ronda 3 y no es interoperable con él. Lo activan por defecto Chrome y Edge 131 (noviembre de 2024), Firefox 132, Safari y las plataformas de Apple desde iOS y macOS 26 (2025), OpenSSL 3.5, Go 1.24 y, del lado del servidor, Cloudflare y otras grandes CDN. La IANA lo marca como recomendado (Recommended).
La sobrecarga es pequeña pero visible: el key share, más grande, hace que el ClientHello supere el tamaño de un paquete de red típico, lo que dejó al descubierto equipos intermedios (middleboxes) que gestionan mal los handshakes fragmentados, y un intercambio de claves en OpenSSL 3.6.5 requiere tres operaciones (generación de claves, encapsulación y desencapsulación), a un ritmo de unas 19.000 a 24.000 por segundo en un núcleo de un Apple M4 Max. La comprobación de TLS poscuántico del navegador muestra si tu conexión lo usa.