TLS hybrid key exchange

Hybrid key exchange in TLS 1.3 combines a classical elliptic-curve Diffie–Hellman exchange with a post-quantum key-encapsulation mechanism, deriving the session secret from both shares so the connection stays confidential as long as *either* component holds. The IETF's Hybrid key exchange in TLS 1.3 work defines how the two shares are carried in the handshake, and the dominant instantiation — X25519MLKEM768 — pairs X25519 with ML-KEM-768 under a single TLS named group. It is the practical, already-deployable defense for TLS against the quantum threat.

Why it matters

TLS is the single largest target for harvest-now-decrypt-later: an adversary records handshakes and ciphertext today and decrypts them retroactively once a cryptographically-relevant quantum computer exists. A pure post-quantum exchange would close that window but stake the entire connection on a comparatively young lattice assumption; a hybrid hedges. Because the shared secret is a KDF over both the X25519 output and the ML-KEM-768 output, a break in the lattice scheme leaves you no worse than classical TLS, and a break in X25519 leaves you with post-quantum security. That belt-and-braces property is why every major deployment shipped a hybrid group first rather than a standalone KEM.

How X25519MLKEM768 works on the wire

X25519MLKEM768 is an IETF-specified TLS named ("supported") group registered in the IANA TLS parameters registry with codepoint 0x11EC (4588). A client offers it in the `supported_groups` extension and sends a combined `key_share`; the construction is a simple concatenation of the X25519 share with the ML-KEM-768 encapsulation key (ClientHello) or ciphertext (ServerHello) — a share concatenation, not a cryptographic KEM combiner. The concrete parameters:

• Codepoint 0x11EC (4588), negotiated through `supported_groups` and `key_share` exactly like a classical curve, so no new handshake message is introduced.
• Wire cost: ML-KEM-768 adds roughly 1.1 KB each direction — a 1184-byte encapsulation key from the client and a 1088-byte ciphertext from the server — on top of the 32-byte X25519 share.
• Deployment: negotiated in the field by Chrome, Firefox, Cloudflare, AWS, OpenSSL 3.5+, and BoringSSL/AWS-LC.
• Not X-Wing: the distinct X-Wing KEM combines the same primitives (X25519 + ML-KEM-768) via a SHA3-256-based combiner; X25519MLKEM768 in TLS uses plain share concatenation and is a different construction.

How quantakrypto helps

Turning on TLS hybrid is one config line; rolling it out safely across a fleet is the real work. We inventory where your TLS terminates and rank its harvest-now-decrypt-later exposure (audit), stage the move to X25519MLKEM768 behind the classical fallback and validate it end-to-end against your load balancers, MTU, and middleboxes (migration — see our guide on migrating TLS to hybrid), and conformance-test the ML-KEM-768 implementation underneath the handshake against FIPS 203's input checks (certification). The result is a TLS estate that is post-quantum-ready without a wave of stalled connections.