Post-quantum TLS

Post-quantum TLS is the adaptation of Transport Layer Security to resist attack by quantum computers. In practice it means TLS 1.3 connections negotiate a hybrid key exchange that combines an elliptic curve agreement (X25519) with the lattice-based ML-KEM key encapsulation mechanism, so that traffic recorded today cannot be decrypted later by a quantum computer.

#Why key exchange moved first

A TLS connection uses public-key cryptography in two places: an ephemeral key exchange that establishes session keys and provides forward secrecy, and certificate signatures that authenticate the server. The key exchange is the urgent target because encrypted traffic can be recorded now and decrypted once a sufficiently capable quantum computer can run Shor's algorithm, the pattern known as harvest now, decrypt later. Signatures matter only at the moment of connection: an attacker who forges them years from now gains nothing against past sessions. Deployments therefore upgraded confidentiality first and left authentication for a second phase (PKI migration to post-quantum).

#How hybrid key exchange works

TLS 1.3 negotiates key exchange through named groups, and a post-quantum hybrid group registers like any other. Its key share concatenates two values: an X25519 public key and an ML-KEM encapsulation key. The server replies with its own X25519 share plus an ML-KEM ciphertext, and the two resulting shared secrets are concatenated and fed into the TLS 1.3 key schedule. Session keys stay secure if either component resists attack, the defining property of hybrid cryptography. The construction and its rationale are analyzed in the IETF draft Hybrid key exchange in TLS 1.3.

Two group codepoints matter historically. X25519Kyber768Draft00 paired X25519 with the pre-standard version of Kyber-768 and carried deployment from 2022 into 2024. After NIST finalized FIPS 203 in August 2024, deployments moved to X25519MLKEM768, specified in draft-kwiatkowski-tls-ecdhe-mlkem along with hybrids of ML-KEM and the NIST P-256 and P-384 curves.

The main cost is size. An ML-KEM-768 encapsulation key adds 1184 bytes to the ClientHello and the ciphertext adds 1088 bytes to the server's reply, roughly 2 KB per handshake in total. Computation is not the bottleneck: ML-KEM operations are fast on modern hardware, and the larger ClientHello is the more visible deployment problem (see browser post-quantum adoption).

#Deployment history

Google ran early hybrid experiments in Chrome, CECPQ1 (X25519 plus NewHope) in 2016 and CECPQ2 (X25519 plus NTRU-HRSS) with Cloudflare in 2019, and Cloudflare enabled hybrid Kyber key agreement across its network in 2022 and 2023. Chrome began enabling X25519Kyber768Draft00 for a portion of users in Chrome 116 in August 2023, turned it on by default in Chrome 124 in April 2024, and switched to X25519MLKEM768 in Chrome 131 in November 2024. Firefox added support for the ML-KEM hybrid beginning with Firefox 128. On the server side, BoringSSL implements the hybrid groups, and OpenSSL added ML-KEM support in version 3.5 (openSSL post-quantum support). The browser rollout is covered in detail in browser post-quantum adoption.

#Adoption statistics

In early March 2024 Cloudflare measured about 2 percent of TLS 1.3 connections using post-quantum key exchange. One year later, after the browser defaults landed, Cloudflare reported that over one third of human-generated traffic reaching its network was protected by post-quantum key exchange. As of early 2026 the share has continued to grow as browser defaults reach more users; Cloudflare Radar publishes a live breakdown. Automated (bot and API) traffic lags well behind human traffic because long-tail clients and origin servers update slowly.

#The harder second phase: certificates

Authenticating TLS with post-quantum signatures is a much larger project than swapping the key exchange. An ML-DSA-44 certificate carries a 1312 byte public key and a 2420 byte signature, against a few dozen bytes for elliptic curve equivalents. A typical certificate chain contains several signatures and public keys plus embedded certificate transparency timestamps, so a naive post-quantum chain grows by roughly 8 to 10 KB, which hurts handshake latency and breaks assumptions in constrained TLS stacks. Certificate issuance also depends on root programs, certificate authorities, and hardware security modules moving together. As of early 2026 the public web PKI does not issue post-quantum certificates in production; the moving parts are described in PKI migration to post-quantum.

#Standards status

As of early 2026 the hybrid groups have registered codepoints and are deployed at Internet scale, while the defining documents remain IETF drafts rather than published RFCs: draft-ietf-tls-hybrid-design for the general construction and draft-kwiatkowski-tls-ecdhe-mlkem for the concrete groups. The underlying KEM, FIPS 203, is final. Codepoints for pure (non-hybrid) ML-KEM groups have also been proposed for environments whose policies prefer standalone post-quantum algorithms; the trade-offs between the two approaches are discussed under hybrid cryptography.