We previously posted about experimenting with a hybrid post-quantum key exchange, and enabling it for 100% of Chrome Desktop clients. The hybrid key exchange used both the pre-quantum X25519 algorithm, and the new post-quantum algorithm Kyber. At the time, the NIST standardization process for Kyber had not yet finished.
Since then, the Kyber algorithm has been standardized with minor technical changes and renamed to the Module Lattice Key Encapsulation Mechanism (ML-KEM). We have implemented ML-KEM in Google’s cryptography library, BoringSSL, which allows for it to be deployed and utilized by services that depend on this library.
The changes to the final version of ML-KEM make it incompatible with the previously deployed version of Kyber. As a result, the codepoint in TLS for hybrid post-quantum key exchange is changing from 0x6399 for Kyber768+X25519, to 0x11EC for ML-KEM768+X25519. To handle this, we will be making the following changes in Chrome 1311:
Chrome will switch from supporting Kyber to ML-KEM
Chrome will offer a key share prediction for hybrid ML-KEM (codepoint 0x11EC)
The PostQuantumKeyAgreementEnabled flag and enterprise policy will apply to both Kyber and ML-KEM
Chrome will no longer support hybrid Kyber (codepoint 0x6399)
Chrome will not support Kyber and ML-KEM at the same time. We made this decision for several reasons:
Kyber was always experimental, so we think continuing to support it risks ossification on non-standard algorithms.
Post-quantum cryptography is too big to be able to offer two post-quantum key share predictions at the same time.
Server operators can temporarily support both algorithms at the same time to maintain post-quantum security with a broader set of clients, as they update over time.
We do not want to regress any clients’ post-quantum security, so we are waiting until Chrome 131 to make this change so that server operators have a chance to update their implementations.
Longer term, we hope to avoid the chicken-and-egg problem for post-quantum key share predictions through our emerging IETF draft for key share prediction. This allows servers to broadcast what algorithms they support in DNS, so that clients can predict a key share that a server is known to support. This avoids the risk of an extra round trip, which can be particularly costly when using large post-quantum algorithms.
We’re excited to continue to improve security for Chrome users, against both current and future computers.
Notes
Chrome Canary, Dev, and Beta may see these changes prior to Chrome 131. ↩