Google is updating the post-quantum cryptography used in the Chrome browser to protect against TLS attacks using quantum computers and to mitigate store-now-decrypt-later attacks.
The upcoming change will swap Kyber used in hybrid key exchanges to a newer, and slightly modified version, renamed as Module Lattice Key Encapsulation Mechanism (ML-KEM).
This change comes roughly five months after Google rolled out the post-quantum secure TLS key encapsulation system on Chrome stable for all users, which also caused some problems with TLS exchanges.
The move from Kyber to ML-KEM though is not related to those early problems, that got resolved soon after manifesting. Rather, its a strategic choice to abandon an experimental system for a NIST-approved and fully standardized mechanism.
ML-KEM was fully endorsed by the U.S. National Institute of Standards and Technology (NIST) in mid-August, with the agency publishing the complete technical specifications of the final version at the time.
Google explains that despite the technical changes from Kyber to ML-KEM being minor, the two are essentially incompatible, so a switch had to be made.
“The changes to the final version of ML-KEM make it incompatible with the previously deployed version of Kyber,” explains Google.
“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.”
Abandoning Kyber
Google explains that support for Kyber has to be removed entirely because post-quantum cryptography involves much larger data sizes compared to pre-quantum algorithms.
For instance, a Kyber-based key exchange can take up over 1,000 bytes, and post-quantum signatures like ML-DSA are even bulkier—leading to over 14,000 bytes in a typical handshake.
Should Google decide to maintain support for Kyber in addition to ML-KEM, network performance and efficiency on Chrome would be seriously hurt.
Google notes that server operators could temporarily support both standards to maintain security for a broader set of clients and help make the transition smoother for clients that haven’t upgraded yet, but ML-KEM should be the final target for all stakeholders.
A proposed solution (IETF draft) for the long term is for servers to announce what cryptographic algorithms they support via DNS, so the client uses the appropriate key from the start, avoiding extra round trips during the handshake.
The update is to be implemented in Chrome 131 (current version is 128), scheduled for release on November 6, 2024.
Users of development channels like Chrome Canary, Beta, and Dev, should see ML-KEM support earlier.
