← Back to release summary

X25519Kyber768 key encapsulation for TLS

Category
Security
Type
New or changed feature
Status
Enabled by default (Chrome 124)
Intent stage
Start prototyping

Summary

Chrome 124 enabled by default on all desktop platforms a new post-quantum secure TLS key encapsulation mechanism [X25519Kyber768](https://developer.chrome.com/blog/chrome-124-beta#x25519kyber768_key_encapsulation_for_tls), based on a NIST standard (ML-KEM). This protects network traffic from Chrome with servers that also support ML-KEM from decryption by a future quantum computer. This change should be transparent to server operators. This cipher will be used for both [TLS 1.3](https://datatracker.ietf.org/doc/html/rfc8446) and [QUIC](https://datatracker.ietf.org/doc/rfc9000/) connections. However, some TLS middleboxes might be unprepared for the size of a Kyber (ML-KEM) key encapsulation, or a new TLS ClientHello cipher code point, leading to dropped or hanging connections. This can be resolved by updating your middlebox, or disabling the key encapsulation mechanism via the temporary [PostQuantumKeyAgreementEnabled](https://chromeenterprise.google/policies/#PostQuantumKeyAgreementEnabled) enterprise policy, which will be available through Chrome 145. However, long term, post-quantum secure ciphers will be required in TLS and the enterprise policy will be removed in Chrome 147. Post-quantum cryptography is required for CSNA 2.0. To learn more, see [Protect Chrome Traffic with Hybrid Kyper KEM](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html).

Motivation

In order to protect today’s network traffic against future quantum cryptanalytic attacks, we need to begin migrating network security protocols, like TLS, to use quantum-resistant cryptography. TLS will need to update to quantum-resistant cryptography in three separate areas: - Establishing, or agreeing upon a symmetric session key - Authenticating the server’s identity (e.g. X.509 certificate validation) - Authenticating the connection was established by the holder of the server’s private key This feature makes incremental progress on “External Encryption in Transit” by migrating TLS key agreement to a Kyber768 key encapsulation mechanism (ISE on Kyber and PQC strategy). Migrating TLS key agreement to quantum-resistant cryptography provides two important properties: - Protecting future network traffic against real-time interception and decryption - Protecting past and current network traffic against the store-and-decrypt attacks While the capability to break currently-deployed cryptography with quantum cryptanalytic attacks has not yet been publicly demonstrated, it is widely accepted that the “store” component of store-and-decrypt attacks are already underway and must be defended against. Past cryptographic algorithm rollouts have demonstrated that these migrations can take a significant amount of time to deploy, so its important to start before quantum computers exist

Standards & signals

Explainers: https://www.ietf.org/archive/id/draft-tls-westerbaan-xyber768d00-02.html

View on chromestatus.com