A brand new path for Kyber on the internet

We beforehand posted about experimenting with a hybrid post-quantum key change, and enabling it for 100% of Chrome Desktop shoppers. The hybrid key change 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 adjustments and renamed to the Module Lattice Key Encapsulation Mechanism (ML-KEM). Now we have carried out ML-KEM in Google’s cryptography library, BoringSSL, which permits for it to be deployed and utilized by providers that rely upon this library.

The adjustments to the ultimate model of ML-KEM make it incompatible with the beforehand deployed model of Kyber. In consequence, the codepoint in TLS for hybrid post-quantum key change is altering from 0x6399 for Kyber768+X25519, to 0x11EC for ML-KEM768+X25519. To deal with this, we shall be making the next adjustments in Chrome 131¹:

• Chrome will change from supporting Kyber to ML-KEM
• Chrome will provide 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 is not going to help Kyber and ML-KEM on the identical time. We made this determination for a number of causes:

1. Kyber was at all times experimental, so we predict persevering with to help it dangers ossification on non-standard algorithms.
2. Put up-quantum cryptography is too massive to have the ability to provide two post-quantum key share predictions on the identical time.
3. Server operators can briefly help each algorithms on the identical time to take care of post-quantum safety with a broader set of shoppers, as they replace over time.

We don’t wish to regress any shoppers’ post-quantum safety, so we’re ready till Chrome 131 to make this variation 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 by means of our rising IETF draft for key share prediction. This enables servers to broadcast what algorithms they help in DNS, in order that shoppers can predict a key share {that a} server is thought to help. This avoids the chance of an additional spherical journey, which may be significantly expensive when utilizing massive post-quantum algorithms.

We’re excited to proceed to enhance safety for Chrome customers, in opposition to each present and future computer systems.

Notes