X25519Kyber768 key encapsulation for TLS

at a glance

why it exists

A sufficiently large quantum computer would break the Elliptic Curve Diffie-Hellman key exchange underpinning today's TLS connections. Even though such computers do not yet exist, a "harvest now, decrypt later" attack is possible: an adversary records encrypted traffic today and decrypts it once quantum hardware is available.

X25519Kyber768 is a hybrid mechanism: it runs classical X25519 and post-quantum ML-KEM-768 simultaneously and combines both shared secrets. This means the connection is secure against both classical and quantum attackers — classical security is not weakened, and quantum security is added on top. ML-KEM-768 is based on a NIST Post-Quantum Cryptography standard (FIPS 203).

The key shares for Kyber are approximately 35× larger than an X25519 key exchange, adding around 1–2 KB to TLS handshakes and a 4–6% latency increase in microbenchmarks. In practice, the impact is minimal for most connections.

what changed in Chrome 147

Chrome 124 first shipped X25519Kyber768 as the default key agreement for TLS on desktop. Between Chrome 124 and 146, an enterprise policy (PostQuantumKeyAgreementEnabled) allowed IT administrators to disable the hybrid KEM and fall back to classical X25519 only — useful for testing compatibility with TLS middleboxes that could not handle the larger key shares.

In Chrome 147 this policy escape hatch is removed and X25519Kyber768 becomes mandatory for TLS connections with servers that support it. Servers that do not advertise ML-KEM-768 support continue to negotiate classical X25519 only.

impact on developers and administrators

For most web developers there is nothing to do — Chrome handles key negotiation automatically. The change is relevant to:

• TLS middlebox operators (enterprise proxies, deep-packet inspection appliances): ensure your TLS termination hardware supports ClientHello messages with the X25519Kyber768Draft00 or X25519MLKEM768 groups. Devices that cannot handle the larger handshake may need firmware updates.
• Enterprise Chrome administrators who relied on PostQuantumKeyAgreementEnabled = false: this policy is gone in Chrome 147. Update TLS infrastructure before deploying Chrome 147 to avoid connectivity failures with internal TLS proxies.
• Server operators: no action required if your server negotiates TLS normally. Servers that only support classical groups will continue to work; Chrome will fall back to X25519 only in that case.

# OpenSSL 3.5+: inspect the negotiated TLS 1.3 group on a supporting server
openssl s_client -connect www.cloudflare.com:443 -servername www.cloudflare.com -tls1_3 -groups X25519MLKEM768 </dev/null 2>&1 | grep 'Server Temp Key'

Group-status disagreement, both sides reported rather than resolved: this page tells middlebox operators to accept both X25519Kyber768Draft00 and X25519MLKEM768, while RFC 10024 — the document draft-ietf-tls-ecdhe-mlkem was published as — states the X25519Kyber768Draft00 registry entry is obsolete (fetched 2026-10-06). The ChromeStatus record cited above still points its own spec_link at the older draft-tls-westerbaan-xyber768d00-02.

browser support

The IETF TLS specification describes the key exchange, not which browsers have shipped it. Chrome's policy change does not imply the same behavior in other engines.

see also

• Chrome Platform Status — X25519Kyber768 key encapsulation for TLS
• blink-dev Intent to Ship: X25519Kyber768 key encapsulation for TLS on Desktop