A practical guide to hybrid TLS

The problem hybrid solves

Two clocks are out of sync. Quantum computers capable of breaking RSA and elliptic-curve cryptography are approaching, while the post-quantum algorithms meant to replace them are new and have far less real-world exposure than the classical schemes they succeed. Committing entirely to a young algorithm carries its own risk; staying entirely classical guarantees eventual failure.

Hybrid cryptography resolves the dilemma by refusing to choose. It runs both in parallel.

How it works in TLS 1.3

In a hybrid TLS 1.3 handshake, the client offers two key shares instead of one — a classical share and a post-quantum share:

1. The ClientHello carries both an X25519 ephemeral public key and an ML-KEM encapsulation key, advertised as a single hybrid named group (for example, X25519MLKEM768).
2. The server performs both key exchanges and returns its corresponding shares.
3. Each side derives two shared secrets — one classical, one post-quantum — and concatenates them into the key schedule that produces the session keys.

Because the final session key is derived from both secrets, the channel stays secure as long as at least one of the two exchanges is unbroken.

It's already in production

Hybrid key exchange is not a lab experiment. It runs today across some of the largest networks on the internet:

• Google Chrome shipped hybrid key exchange to billions of connections, making it a default part of everyday web traffic.
• Cloudflare moved from early experiments to production hybrid key exchange across its global network.
• Major cloud and messaging providers have deployed hybrid key exchange in TLS and their own protocols.

That production track record is precisely why hybrid is the low-risk first move: the interoperability and performance questions have already been answered at scale.

The overhead is modest

The most common objection is cost. In practice it is small:

A hybrid ClientHello grows from tens of bytes of key share to roughly a kilobyte, and the added computation is sub-millisecond on modern hardware. For the overwhelming majority of applications, this is operationally trivial — a rounding error against the value of the data being protected.

Sequencing: key exchange first

Of all the steps in a hybrid migration, key exchange should go first, and for a specific reason: it is what defeats harvest-now-decrypt-later. Protecting the key exchange today stops an adversary from decrypting a session later, even if they recorded every byte of it.

Signatures are the harder problem and can follow. They touch certificate chains, public-key infrastructure, and long-lived trust anchors, and post-quantum signatures are larger — so they need more planning. Crucially, though, unmigrated signatures do not expose past traffic the way unmigrated key exchange does. Don't let the harder problem block the urgent one.

A four-phase rollout

1. Inventory your TLS endpoints and prioritize anything carrying long-lived confidential data.
2. Enable hybrid key exchange on internal and high-sensitivity services first.
3. Validate that the hybrid group is actually being negotiated, and monitor it as your crypto-agility baseline.
4. Extend to signatures and PKI once key exchange is stable.

Related: CNSA 2.0 primer · Mosca's Inequality · Briefings