If you have visited any reasonably modern website in the last two years and looked at the TLS connection details, you may have seen a key exchange algorithm with a name like X25519MLKEM768 or X25519Kyber768Draft00. Those are hybrid post-quantum key exchanges, and they are already protecting more than half of all browser-to-server TLS traffic on the public internet, with Cloudflare reporting over 60% adoption among compatible clients in their 2025 telemetry.
This is not theoretical. This is shipped, deployed, debugged, in production, today. The largest CDN in the world is encrypting traffic with a key exchange that combines a classical Diffie-Hellman variant (X25519) with a NIST-standardized post-quantum Key Encapsulation Mechanism (ML-KEM-768).
This blog post explains how that hybrid handshake actually works, what changes from a classical TLS 1.3 handshake, and what the practical operational implications are.
TLS 1.3 In Two Paragraphs
TLS 1.3, defined in RFC 8446, is the current standard for transport-layer encryption. It replaced TLS 1.2 with a leaner, faster, more secure protocol. The handshake is one round-trip in the common case (1-RTT), uses authenticated encryption with associated data (AEAD) for all encrypted records, and removes a long list of weak ciphers that plagued earlier TLS versions.
The cryptographic core is straightforward: the client and server agree on a shared secret using ephemeral Diffie-Hellman (typically over Curve25519 or NIST P-256), the server authenticates with a certificate (RSA or ECDSA), both sides derive session keys from the shared secret, and all subsequent traffic is encrypted with AES-GCM or ChaCha20-Poly1305.
The cryptographic core is also exactly what quantum computers threaten. Diffie-Hellman over X25519 is broken by Shor's algorithm. RSA and ECDSA signatures are broken by Shor's algorithm. The whole structure of TLS 1.3 falls if a sufficiently large quantum computer exists.
Why Hybrid Instead Of Pure PQC
The natural question is: if ML-KEM is NIST-standardized and ready, why not just replace X25519 with ML-KEM directly? The answer is conservative engineering.
ML-KEM is new. It was finalized in FIPS 203 in August 2024 after several years of public scrutiny. It is believed secure based on the hardness of Module Learning With Errors (Module-LWE). But "believed secure" is doing real work in that sentence. The cryptographic community has decades of experience with ECC and DH and a deep understanding of what attacks look like. ML-KEM has a few years.
A hybrid handshake combines the established but quantum-vulnerable algorithm (X25519) with the new but quantum-safe algorithm (ML-KEM-768). The shared secret is derived from both. If either algorithm is broken, by quantum attack on X25519, or by an unforeseen mathematical break on ML-KEM, the other still protects the connection.
This is the same logic as belt-and-braces seatbelts in a race car. We have a whole article on hybrid encryption that goes deeper into why this matters and how the combination works mathematically.
The Hybrid Group: X25519MLKEM768
The IETF has registered named groups in the TLS Supported Groups Registry for hybrid PQC. The current production-deployed identifier is X25519MLKEM768 (registry value 0x11ec at time of writing; check IANA for current). Earlier deployments used X25519Kyber768Draft00 (0x6399), where Kyber was the pre-standardization name for ML-KEM. The two are interoperable in concept but use slightly different message formats; the ML-KEM-final one is the future.
Inside the handshake, the named group identifier appears in two places:
- ClientHello: the client lists the groups it supports in the
supported_groupsextension and includes a key share for each group it is willing to start the handshake with in thekey_shareextension. - ServerHello: the server picks one group and sends back its corresponding key share.
For X25519MLKEM768, the client's key share is the concatenation of (note the order: despite the name, the ML-KEM part comes first on the wire):
- A 1,184-byte ML-KEM-768 encapsulation (public) key
- A 32-byte X25519 public key
That is 1,216 bytes total in the client's key share for this single group. Compare to a classical X25519-only key share at 32 bytes. The handshake is roughly 1,184 bytes larger when going hybrid, all in the ClientHello.
The server's key share is similarly the concatenation of (ML-KEM part first again):
- A 1,088-byte ML-KEM-768 ciphertext (the encapsulation result against the client's ML-KEM public key)
- A 32-byte X25519 public key (the server's ephemeral public key)
That is 1,120 bytes in the ServerHello. Again, roughly 1,088 bytes larger than classical.
Deriving The Shared Secret
The combined shared secret is the concatenation of the two component shared secrets, ML-KEM first, matching the wire order:
`` combined_shared_secret = ML-KEM_shared_secret || X25519_shared_secret ``
That combined secret is then fed into TLS 1.3's HKDF-based key schedule, exactly as a classical shared secret would be. The rest of the handshake is unchanged: certificate verification, Finished messages, the whole protocol after the key exchange is identical.
This concatenation approach is intentionally simple. More complex combiners (like running a KDF over both secrets first) add nothing in terms of security in this context: if you have two sources of entropy, and at least one is unguessable, the concatenation is also unguessable. The TLS WG analyzed this carefully and chose the simple path.
Cloudflare Telemetry: 60% And Climbing
Cloudflare publishes regular blog posts about their PQC deployment numbers. As of mid-2025, more than 60% of compatible clients (Chrome, Firefox, Edge with their respective PQC builds) connecting to Cloudflare-fronted sites are using X25519MLKEM768. That number was below 5% just two years ago. The growth is driven by browser auto-rollout: Chrome enabled it by default in 2024, and Firefox followed in 2025.
For operators of TLS servers, this means PQC is no longer an experiment. It is in production, at scale, with real performance data behind it.
The Cloudflare numbers also tell us something useful about performance: the hybrid handshake adds roughly 4–5 ms to handshake latency in median measurements, primarily from the bandwidth of the larger ClientHello and ServerHello. CPU cost is negligible, ML-KEM key generation and encapsulation run in well under a millisecond on modern hardware.
ClientHello Fragmentation: The QUIC Edge Case
For TLS over TCP, the larger ClientHello is annoying but not fatal. TCP has no MTU sensitivity inside an established connection. The ClientHello might span multiple segments, but reassembly is transparent.
For TLS over UDP, which means QUIC, which means HTTP/3, the larger ClientHello can break things. QUIC's Initial packets must fit within roughly 1,200 bytes. A hybrid ClientHello easily exceeds this. The fix is to fragment the ClientHello across multiple QUIC packets and reassemble at the server. This is messier, has ample edge cases, and is being addressed in the QUIC PQC implementation work.
For middleboxes (firewalls, deep-packet-inspection appliances) that look at TLS traffic, larger ClientHellos sometimes trigger pathological behavior. Some old middleboxes drop packets above a fixed size. Others fail to parse the larger ClientHello correctly. There is a multi-year effort to identify and fix these.
What About Certificate Signatures?
The X25519MLKEM768 hybrid handles the key exchange. But TLS 1.3 also uses signatures during the handshake, the server signs a transcript hash with the certificate's private key to prove ownership.
Today those signatures are RSA, ECDSA, or Ed25519. None are quantum-safe. The hybrid handshake does not protect them: a quantum-capable adversary who captures the handshake can later derive the certificate's private key from its public key, retroactively breaking the signature.
The good news is that retroactive breaking of a signature does not retroactively break the connection. The connection's session keys come from the (hybrid, quantum-safe) key exchange. An attacker can later forge a signature, but they cannot retroactively decrypt the session.
The bad news is that future connections to that certificate become vulnerable: an attacker with the derived private key can impersonate the server going forward.
This is why TLS PQC migration has two phases. Phase one (now) is hybrid key exchange. Phase two (future) is PQC signatures, using ML-DSA. The IETF is working on this. CA/Browser Forum is tracking the certificate format implications. For details, see our TLS 1.2 vs TLS 1.3 PQC article and the NIST FIPS guide.
Server Configuration
For a TLS 1.3 server to support hybrid handshakes, it needs a TLS library that understands X25519MLKEM768. Major libraries that ship this today:
- OpenSSL 3.5+ (with provider configuration)
- BoringSSL (Google's fork, since 2023)
- rustls (since 0.23)
- wolfSSL (since 5.7)
- GnuTLS (in development)
A typical OpenSSL configuration to enable the hybrid group:
`` openssl s_server -groups X25519MLKEM768:X25519:secp256r1 ... ``
The order matters: clients negotiate the first group both sides support. Putting X25519MLKEM768 first means PQC-capable clients use it; classical clients fall back to X25519 transparently.
For a deeper look at the OpenSSL and OpenSSH PQC ecosystems, see our OpenSSL PQC status and OpenSSH migration articles.
TLS Resumption And Session Tickets
TLS 1.3 supports session resumption via PSK (pre-shared key) tickets. A client that has previously connected to a server can present a ticket and skip the full handshake, reducing latency dramatically.
For PQC, session resumption is somewhat less of a win than in classical TLS. The reason: the original PQC handshake established hybrid keys, and the resumption derives new keys from those. So a resumed connection inherits the PQC properties of the original. But the resumption itself requires only symmetric crypto, which means resumption is not where the PQC cost lives.
In practice, this means TLS 1.3 with session resumption masks much of the hybrid PQC handshake cost. A long-running browser session resumes connections to popular servers without paying the hybrid handshake cost on every connection.
The catch is that session tickets eventually expire. Default ticket lifetimes are typically 7 days, but some servers issue tickets with shorter or longer lifetimes. When the ticket expires, the next connection requires a fresh hybrid handshake.
0-RTT And PQC
TLS 1.3 also supports 0-RTT data, where the client sends application data along with the ClientHello, encrypted under keys derived from a previously-resumed PSK. 0-RTT is useful for latency but has known replay attack risks.
For PQC, 0-RTT works the same way as in classical TLS. The 0-RTT keys are derived from the resumed PSK, which itself was derived from an earlier hybrid handshake. So the cryptographic protection is hybrid, even on 0-RTT data.
What QNSQY Does
QNSQY itself does not currently use TLS for the actual file encryption, the cryptographic envelope is built into the QSPG v2 file format and travels via whatever transport the user picks (file copy, email attachment, S3 upload, sneakernet). But QNSQY's billing API runs over HTTPS, and we have hybrid PQC enabled at the Cloudflare edge.
Every TLS 1.3 connection to api.quantumsequrity.com that comes from a hybrid-capable browser (Chrome 124+, Firefox 132+, Edge 126+, Safari 18.2+) negotiates X25519MLKEM768. Older clients fall back to X25519. You can verify this yourself in seconds with our free checker at quantumsequrity.com/pqc-check.
Frequently Asked Questions
Q: Is X25519MLKEM768 quantum-safe? The ML-KEM-768 component is quantum-safe in the sense that NIST has standardized it as such, based on the hardness of Module-LWE. The X25519 component is not quantum-safe but provides classical security as a safety net. The combined construction is quantum-safe as long as ML-KEM-768 holds.
Q: How much slower is the hybrid handshake? Roughly 4–5 ms median latency added, plus 2.3 KB of bandwidth in the ClientHello and 2.2 KB in the ServerHello. CPU cost is sub-millisecond. For most applications, this is invisible.
Q: Will browsers warn users about hybrid PQC connections? No. The connection looks like a normal HTTPS connection from the user's perspective. Only browser developer tools show the negotiated group.
Q: What if my server is behind a load balancer that does not understand the hybrid group? The load balancer will probably terminate TLS itself and re-encrypt to the backend. As long as the load balancer supports X25519MLKEM768, the client-facing connection is PQC. The backend connection between LB and server is a separate concern (usually inside a private network where PQC matters less, but still worth migrating).
Q: Should I disable classical groups entirely? No, not yet. The vast majority of legacy clients (older browsers, IoT devices, embedded systems) only speak classical. Disabling X25519 and P-256 will break compatibility for a huge fraction of clients. Deploy hybrid as additive, not replacement.
Sources
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3. https://datatracker.ietf.org/doc/html/rfc8446
- NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism. https://csrc.nist.gov/pubs/fips/203/final
- Cloudflare Research, The state of the post-quantum Internet. https://blog.cloudflare.com/pq-2024/
- IANA TLS Supported Groups Registry. https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
- draft-ietf-tls-hybrid-design, Hybrid key exchange in TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Related Articles
- What Is Post-Quantum Cryptography?
- ML-KEM Explained
- Hybrid Encryption
- TLS 1.2 vs TLS 1.3 PQC
- Harvest Now, Decrypt Later
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.