v147 · stepped rollout · security · tls · post-quantum
X25519Kyber768 key encapsulation for TLS
Chrome 147 completes the rollout of X25519Kyber768, a hybrid post-quantum key encapsulation mechanism (KEM) for TLS 1.3. The combination of classical X25519 and ML-KEM-768 (formerly Kyber768) protects HTTPS traffic from future quantum computers that could decrypt today's recorded sessions. Chrome 147 also removes the enterprise policy that previously allowed administrators to opt out.
PostQuantumKeyAgreementEnabled enterprise policy that allowed disabling X25519Kyber768 is removed in Chrome 147. All Chrome 147+ connections use the post-quantum hybrid KEM when the server also supports it.
at a glance
| Initially shipped | Chrome 124 (desktop, enabled by default) |
|---|---|
| Chrome 147 change | Stepped rollout completes; PostQuantumKeyAgreementEnabled enterprise override removed |
| Algorithm | Hybrid X25519 + ML-KEM-768 (X25519Kyber768 / IETF draft) |
| Affects | All TLS 1.3 connections where the server supports the hybrid KEM |
| ChromeStatus | 5257822742249472 — X25519Kyber768 key encapsulation for TLS |
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.
Source: chromestatus.com/feature/5257822742249472; IETF draft-ietf-tls-ecdhe-mlkemwhat 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.
Source: chromestatus.com/feature/5257822742249472impact 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
X25519Kyber768Draft00orX25519MLKEM768groups. 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.