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
[…]
Content was cut in order to protect the source.Please visit the source for the rest of the article.This article has been indexed from Google Online Security BlogRead the original article: