How Post-Quantum Cryptography Works in TLS 1.3: The Hybrid Handshake Explained

Brian Couzens

2 minutes ago

6 min read

Two light streams braiding into one key on navy, representing hybrid post-quantum key exchange in TLS 1.3.

Post-quantum cryptography is already running inside TLS 1.3. This explainer walks through the hybrid handshake, X25519MLKEM768, step by step: what changes on the wire, why certificates are still classical, where the larger messages cause failures, and how to test post-quantum TLS on your own servers.

The short answer

When a current browser connects to a server that supports it, the two sides now agree their session keys with two methods at once: the classical X25519 key exchange and ML-KEM-768, the post-quantum key-encapsulation mechanism NIST standardised as FIPS 203 in August 2024. The combination is called X25519MLKEM768. The IETF published it as RFC 10024 in August 2026, after browsers and content delivery networks had already deployed it at scale.

What has not changed is authentication. The certificate that proves the server's identity, and the signature inside the handshake, are still RSA or elliptic curve. Post-quantum key exchange protects the confidentiality of a TLS session today. Post-quantum authentication is a separate, slower migration.

Two jobs in every TLS 1.3 handshake

A TLS 1.3 handshake does two jobs. It agrees a shared secret that encrypts the session, and it authenticates the server through a certificate chain and a signature over the handshake.

The two jobs face the quantum threat on different timelines. An adversary can record an encrypted session today and decrypt it once a cryptographically relevant quantum computer exists. That is harvest now, decrypt later, and it is a key exchange problem. Forging a handshake signature only helps an attacker who can impersonate a server live, so for ordinary TLS sessions the authentication risk arrives with the machine itself. Long-lived trust material, such as root certificates and signing keys, is the exception. SITG-Consulting has set out the difference between harvest now, decrypt later and harvest now, forge later. It explains why key exchange moved first: recorded traffic carrying data that must stay confidential for years is already exposed.

The hybrid handshake, step by step

The client lists X25519MLKEM768 in its supported_groups extension and sends a key share for it in the ClientHello. That share is 1,216 bytes, made up of a 1,184-byte ML-KEM-768 encapsulation key and a 32-byte X25519 public key.
A server that supports the group replies with its own share in the ServerHello. That share is 1,120 bytes: a 1,088-byte ML-KEM ciphertext and the server's 32-byte X25519 public key.
Each side now holds two secrets, one from ML-KEM and one from X25519. RFC 10024 concatenates them, ML-KEM first, into a single 64-byte shared secret that feeds the normal TLS 1.3 key schedule.
Everything after that point, from the server certificate onwards, is encrypted exactly as before.

A server that does not support the group picks a classical one the client also offered, such as X25519. If the client sent no key share for the group the server wants, the server answers with a HelloRetryRequest and the client tries again, at the cost of one extra round trip.

RFC 10024 registers three hybrid groups: X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) and SecP384r1MLKEM1024 (0x11ED). The first is the one Chrome and Apple's operating systems send by default.

Why hybrid, not ML-KEM alone

ML-KEM is new. The hybrid construction keeps the session confidential as long as either component holds: a mathematical weakness found in ML-KEM does not expose the session, and neither does a quantum computer that breaks X25519. That is why hybrid is the default on the public web today.

Hybrid is a bridge, not the end state. It carries two algorithms, two code paths and larger messages, and every one of those has to be proven in your own environment before it is relied on. SITG-Consulting's framework for a first hybrid pilot covers how to prove a hybrid deployment, with rollback, before extending it.

Post-quantum key exchange needs TLS 1.3

RFC 10024 defines the hybrid groups for TLS 1.3. There is no equivalent standard for TLS 1.2, so a service that still negotiates TLS 1.2 cannot offer post-quantum key exchange at all. Legacy protocol versions are now a quantum exposure as well as a classical one.

The IETF's July 2026 revision of TLS 1.3, RFC 9846, already forbids negotiating TLS 1.0 and 1.1. SITG-Consulting covered that change in TLS 1.3 hasn't become TLS 1.4.

The size problem: split ClientHellos and middleboxes

An X25519 key share is 32 bytes. The hybrid share is 1,216. That pushes the ClientHello past the size of a single network packet, so it is typically split across two packets. Two failure modes follow.

First, some servers assume the whole ClientHello arrives in a single read. Faced with a split one, they reset the connection instead of falling back to classical key exchange. The tldr.fail project documents the bug and how to test for it, and Apple warns that some legacy servers will fail to connect to iOS 26 and macOS Tahoe 26 for this reason.

Second, load balancers, firewalls and inspection devices sit in the path and must handle the larger message too. A TLS-terminating proxy that does not support the hybrid group removes the protection from every connection behind it, whatever the server supports. Mapping where TLS actually terminates matters as much as mapping servers; see node versus endpoint in PQC migration. The wider negotiation risks, including downgrade, are set out in interoperability in post-quantum cryptography.

Where a server supports the group but prefers another, the HelloRetryRequest costs a round trip. When Cloudflare measured its connections to customer origin servers, about 52 per cent of handshakes to scanned origins needed a retry before it began probing each origin's preference; afterwards, 3.7 per cent did. The same measurement found that only 12.8 per cent of origins supported post-quantum key exchange.

Certificates and signatures are still classical

Key exchange is largely solved on the public web. Authentication is not. Each TLS handshake carries several public keys and signatures: the server certificate, the intermediate certificate, the handshake signature and, on the public web, Certificate Transparency timestamps.

ML-DSA, the post-quantum signature standard in FIPS 204, is far larger than what it replaces. An ML-DSA-44 signature is 2,420 bytes and its public key 1,312 bytes; an ML-DSA-65 signature is 3,309 bytes. An elliptic curve P-256 signature is about 64 bytes. SITG-Consulting's analysis of post-quantum key sizes sets out the knock-on effects for networks, devices and storage.

Browsers do not all support post-quantum certificates yet, and servers must keep serving clients that do not. Cloudflare's roadmap puts post-quantum authentication for visitor connections at mid-2027, using Merkle Tree Certificates, and full post-quantum security across its products at 2029. Inside an organisation, the timetable is set by its own PKI, hardware security modules and clients, compounded by public certificate lifetimes falling to 47 days by March 2029.

Who has deployed post-quantum TLS

Chrome switched from the earlier Kyber draft to ML-KEM, codepoint 0x11EC, in Chrome 131 (Google Security Blog, September 2024).
Apple's iOS 26, iPadOS 26, macOS Tahoe 26 and visionOS 26 advertise hybrid key exchange in TLS 1.3 automatically (Apple).
OpenSSL 3.5.0, released on 8 April 2025, offers X25519MLKEM768 and X25519 as its default key shares (OpenSSL release notes).
Cloudflare reported in April 2026 that over 65 per cent of human traffic to its network was post-quantum encrypted (Cloudflare).

The client side has moved. The gap is on the server side and in everything between client and server.

How to test post-quantum TLS on your own servers

With OpenSSL 3.5 or later, offer only the hybrid group:

openssl s_client -connect example.com:443 -groups X25519MLKEM768

If the handshake completes with only that group offered, the server supports it, and the output names the negotiated group.

On macOS Tahoe 26, run nscurl --tls-diagnostics https://example.com. A server that supports the group reports X25519MLKEM768 as the negotiated key exchange (Apple).
In Chrome, the Security panel in Developer Tools shows the key exchange group for the current connection.

Test from inside the network as well as outside. The answer from the internet tells you what your edge does. It says nothing about the internal service behind a TLS-terminating load balancer.

What to do now

Map every point where TLS terminates: servers, load balancers, reverse proxies, VPN gateways, inspection devices and service meshes. Each one is where post-quantum protection starts or stops, and discovery tools can miss them; seeshadow cryptography.
Move terminating services to libraries that support the hybrid groups, such as OpenSSL 3.5 or later, and confirm the group is enabled, not merely available.
Test for split-ClientHello failures before clients force the issue. Browsers and operating systems already send the hybrid share by default.
Retire TLS 1.2 where you can. It cannot carry post-quantum key exchange.
Check FIPS 140-3 validation where it binds you. A module's validated status is tied to its version and boundary, so an upgrade for ML-KEM support can change your compliance position; see FIPS 140-3 gap analysis.
Plan certificates as a separate programme: PKI, hardware security modules, certificate lifecycle automation and the 47-day schedule.
Record evidence. One handshake that negotiates X25519MLKEM768 in one test is not proof across an estate; deploying PQC is not the same as proving it works.

About the author

Brian Couzens is CEO of SITG-Consulting, an independent advisory firm working on post-quantum transformation, cryptographic governance and assurance. SITG-Consulting provides cryptographic agility services and independent PQC assurance.

SITG-CONSULTING