Last updated: 2026-06-25

Post-Quantum TLS: Hybrid Key Exchange

This guide explains how to deploy post-quantum (PQ) key exchange in TLS 1.3 today. Unlike the per-application guides on this site, this is a cross-cutting reference: the same hybrid key-exchange group, X25519MLKEM768, is enabled the same way across the major TLS stacks, and the guidance here applies to any server those stacks power.

Why now: harvest-now, decrypt-later#

A large-scale quantum computer does not exist yet, but the threat to TLS is already present. An attacker can record encrypted traffic today and decrypt it years later once a cryptographically relevant quantum computer can run Shor's algorithm against the elliptic-curve key exchange that protects a TLS session. Any data with a long confidentiality lifetime (health records, credentials, source code, legal documents) is exposed to this "harvest-now, decrypt-later" model the moment it crosses the wire.

Post-quantum key exchange closes that window. It does not depend on quantum computers existing yet; it protects today's traffic against tomorrow's decryption.

What changed: hybrid key exchange#

TLS 1.3 negotiates a shared secret using a named group (an elliptic curve such as X25519). The post-quantum upgrade replaces that single group with a hybrid group that runs a classical and a post-quantum algorithm together and mixes both outputs into the session key:

• X25519 - the classical Elliptic Curve Diffie-Hellman exchange, unchanged.
• ML-KEM-768 - the Module-Lattice Key Encapsulation Mechanism standardised by NIST in FIPS 203 (August 2024), believed to resist quantum attack.

The combined group is named X25519MLKEM768 (IANA codepoint 0x11EC). Hybrid is deliberate: the session stays at least as strong as X25519 even if a weakness is later found in ML-KEM, and at least as strong as ML-KEM even if a quantum computer breaks X25519. You are never worse off than the classical baseline.

An earlier, pre-standard hybrid named X25519Kyber768Draft00 (codepoint 0x6399) was deployed by some browsers and CDNs in 2023 and 2024. It is now superseded by X25519MLKEM768; prefer the standardised group and retire the draft one.

What is and is not protected#

Key exchange is the urgent half because it is what harvest-now-decrypt-later attacks. Authentication can be migrated later: a forged signature requires a quantum computer that exists at the time of the attack, so there is no retroactive risk. See the roadmap below.

Standards and algorithms#

X25519MLKEM768 is the group to deploy: it is what browsers and CDNs negotiate in practice (Cloudflare reports it as the large majority of post-quantum connections it sees).

Support as of 2025#

Distribution OpenSSL still matters: Debian 12 and Ubuntu 24.04 ship OpenSSL 3.0, which does not include ML-KEM. Hybrid key exchange on those platforms requires OpenSSL 3.5+ (or a stack that bundles its own TLS, like any Go server).

Enabling hybrid key exchange#

In every case below, the classical groups are kept in the list as a fallback so that clients without PQ support still negotiate a secure (classical) session.

OpenSSL 3.5 (test client)#

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

A successful handshake reports Negotiated TLS1.3 group: X25519MLKEM768.

nginx (OpenSSL 3.5+)#

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Apache httpd (OpenSSL 3.5+)#

SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256

HAProxy 3.x (OpenSSL 3.5+)#

ssl-default-bind-curves X25519MLKEM768:X25519:secp256r1

Caddy 2.10+#

No configuration is required; X25519MLKEM768 is offered by default. Note that explicitly setting key_exchange_algorithms (or curves) replaces the defaults, so include x25519mlkem768 in any custom list or you will disable the post-quantum group.

Go servers (Go 1.24+)#

No code change is needed. A *tls.Config with CurvePreferences left unset offers X25519MLKEM768 by default. Setting CurvePreferences explicitly overrides this, so include tls.X25519MLKEM768 in the list if you pin curves. To disable for debugging, run with GODEBUG=tlsmlkem=0.

Verifying#

• OpenSSL: openssl s_client -groups X25519MLKEM768 -connect host:443 and look for Negotiated TLS1.3 group: X25519MLKEM768.
• Browser: open the site and inspect the connection security details, or use a checker such as the Cloudflare post-quantum test page.
• testssl.sh: recent versions report the negotiated key-exchange group, including the hybrid PQ groups.

Deployment considerations#

• ClientHello size. An ML-KEM key share is roughly 1.2 KB, which pushes the ClientHello past a single TCP segment. The handshake still works, but very old or misconfigured middleboxes that mishandle large or fragmented ClientHellos can break it. This was the main cause of the early browser rollout issues; modern stacks negotiate cleanly.
• Fallback is automatic. A client that does not support X25519MLKEM768 simply negotiates a classical group from the rest of the list. Keep X25519 and P-256 in the list for compatibility.
• Performance. ML-KEM is fast; the measurable cost is the extra handshake bytes, not CPU. For most workloads the difference is negligible.
• FIPS environments. Where a FIPS-validated classical curve is mandated, SecP256r1MLKEM768 pairs ML-KEM with P-256 instead of X25519.

Post-quantum signatures and certificates#

Migrating certificate authentication to post-quantum signatures (ML-DSA / FIPS 204, SLH-DSA / FIPS 205) is the next phase and is not yet practical on the public web: CAs do not issue PQ-signed certificates, chains would grow substantially, and client support is early. Because a forged signature is only useful at the moment of an active attack, there is no harvest-now-decrypt-later pressure on authentication, so it is reasonable to deploy hybrid key exchange now and adopt PQ signatures once the certificate ecosystem matures. For long-lived internal PKI (firmware signing, device identity), stateful hash-based signatures (LMS / XMSS, RFC 8554 / RFC 8391) are already standardised and quantum-resistant.

References#

• NIST FIPS 203 (August 2024): Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
• NIST FIPS 204 / 205: ML-DSA and SLH-DSA digital signature standards
• draft-ietf-tls-ecdhe-mlkem: Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3
• RFC 8446 (August 2018): TLS 1.3, which defines the named-group negotiation this builds on
• OpenSSL 3.5 release notes: first upstream release with built-in ML-KEM