We beforehand posted about experimenting with a hybrid post-quantum key trade, and enabling it for 100% of Chrome Desktop purchasers. The hybrid key trade used each the pre-quantum X25519 algorithm, and the brand new post-quantum algorithm Kyber. On the time, the NIST standardization course of for Kyber had not but completed.
Since then, the Kyber algorithm has been standardized with minor technical modifications and renamed to the Module Lattice Key Encapsulation Mechanism (ML-KEM). We’ve applied ML-KEM in Google’s cryptography library, BoringSSL, which permits for it to be deployed and utilized by providers that rely on this library.
The modifications to the ultimate model of ML-KEM make it incompatible with the beforehand deployed model of Kyber. Consequently, the codepoint in TLS for hybrid post-quantum key trade is altering from 0x6399 for Kyber768+X25519, to 0x11EC for ML-KEM768+X25519. To deal with this, we will probably be making the next modifications in Chrome 1311:
- Chrome will swap from supporting Kyber to ML-KEM
- Chrome will supply a key share prediction for hybrid ML-KEM (codepoint 0x11EC)
- The PostQuantumKeyAgreementEnabled flag and enterprise coverage will apply to each Kyber and ML-KEM
- Chrome will not help hybrid Kyber (codepoint 0x6399)
Chrome won’t help Kyber and ML-KEM on the identical time. We made this resolution for a number of causes:
- Kyber was all the time experimental, so we predict persevering with to help it dangers ossification on non-standard algorithms.
- Publish-quantum cryptography is too large to have the ability to supply two post-quantum key share predictions on the identical time.
- Server operators can quickly help each algorithms on the identical time to take care of post-quantum safety with a broader set of purchasers, as they replace over time.
We don’t need to regress any purchasers’ post-quantum safety, so we’re ready till Chrome 131 to make this modification in order that server operators have an opportunity to replace their implementations.
Long term, we hope to keep away from the chicken-and-egg drawback for post-quantum key share predictions via our rising IETF draft for key share prediction. This enables servers to broadcast what algorithms they help in DNS, in order that purchasers can predict a key share {that a} server is thought to help. This avoids the danger of an additional spherical journey, which might be significantly pricey when utilizing giant post-quantum algorithms.
We’re excited to proceed to enhance safety for Chrome customers, in opposition to each present and future computer systems.
Notes