⏱️ Lectura: 10 min
No quantum computer exists today capable of breaking the encryption that protects an online purchase. Even so, when you open Chrome to visit a site behind Cloudflare, much of that connection already negotiates a key resistant to a quantum computer that hasn’t been built yet. ML-KEM, the standard NIST published as FIPS 203 on August 13, 2024, became integrated by default in the world’s most used browser and in one of the networks that serves the most HTTPS traffic on the planet.
📑 En este artículo
- TL;DR
- What happened
- Context and history
- ML-KEM technical details and performance
- How to test it
- Impact and analysis
- What’s next
- Frequently Asked Questions
- What is ML-KEM and how does it differ from Kyber?
- Why use a hybrid scheme instead of pure post-quantum?
- Is my connection already protected against quantum computers?
- What is harvest now, decrypt later?
- When will certificates and digital signatures be updated to post-quantum?
- Do I need to do anything as a developer?
- References
This migration isn’t an academic exercise. Governments and companies assume someone may be recording encrypted traffic today to decrypt it once a sufficiently powerful quantum machine exists: the strategy known as harvest now, decrypt later. Signal, Apple, and now much of the open web close that blind spot with a hybrid scheme that combines traditional classical encryption with a new algorithm based on mathematical lattices.
TL;DR
- NIST published ML-KEM as the FIPS 203 standard on August 13, 2024, based on the Kyber algorithm.
- Google enabled the hybrid group X25519Kyber768 in Chrome starting in August 2023 and later migrated it to X25519MLKEM768.
- Signal announced PQXDH, its post-quantum key agreement protocol, on September 19, 2023.
- Apple integrated PQ3 into iMessage starting with iOS 17.4, released in February 2024.
- OpenSSH has offered quantum-resistant key exchange by default since version 9.0, from April 2022.
- The scheme is hybrid: it combines X25519 (classical) with ML-KEM-768 (post-quantum), so both must be broken at once.
- The threat driving this migration is called harvest now, decrypt later: recording encrypted traffic today to decrypt it later.
What happened
Google was the first to move a major piece on the board. In August 2023, Chrome started offering a hybrid group called X25519Kyber768 in TLS 1.3 connections, using the version of Kyber that was still a draft in the standardization process. When NIST finalized the standard in August 2024, the algorithm was renamed ML-KEM and the TLS group became X25519MLKEM768. That renaming isn’t cosmetic: the standardization process introduced changes to parameter encoding compared to the original Kyber, so a client running 2023’s Kyber and a server running the final ML-KEM aren’t compatible with each other without updating.
Cloudflare followed the same path at its network edge, and today documents live what portion of the traffic it handles already negotiates a post-quantum group on Cloudflare Radar. Since Chrome accounts for most of the world’s browsing traffic and enables X25519MLKEM768 by default, any server that speaks TLS 1.3 and offers that group ends up using it without the user doing anything.
Context and history
The underlying reason is an algorithm from 1994. Peter Shor showed that a sufficiently large quantum computer can factor integers and compute discrete logarithms in efficient time, precisely the two mathematical problems that RSA and elliptic curve cryptography (including X25519) rest on. As long as that machine doesn’t exist at a useful scale, RSA and ECC remain secure today. The risk is traffic recorded now and decrypted later.
NIST opened a public call in 2016 to replace those algorithms with others resistant to both classical and quantum computers. After several elimination rounds through public cryptanalysis, in July 2022 it selected CRYSTALS-Kyber for key exchange and CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures. Kyber is based on the Module-LWE problem over lattices: finding a short vector in a many-dimensional grid of points, a problem for which no efficient quantum algorithm like Shor’s is known.
ML-KEM technical details and performance
How the hybrid exchange works
In a TLS 1.3 handshake with X25519MLKEM768, the browser doesn’t send a single public key: it sends two, one from X25519 and one from ML-KEM-768, concatenated in the same ClientHello message. The server responds with its own X25519 key and the ML-KEM ciphertext, and both sides combine the two resulting secrets with a key derivation function (KDF) to obtain the final session secret.
sequenceDiagram
participant N as Browser
participant S as Server
N->>S: ClientHello with X25519 key and ML-KEM-768 public key
S-->>N: ServerHello with ML-KEM ciphertext and X25519 public key
Note over N,S: both derive the same secret by combining the two algorithmsThis hybrid design is deliberate. If a mathematical flaw in lattices surfaces tomorrow and ML-KEM falls, the connection remains protected by X25519. If instead the quantum computer appears and breaks X25519, the connection remains protected by ML-KEM. An attacker needs to break both algorithms at once, not just one.
The cost: larger keys
None of this is free. An X25519 public key is 32 bytes. ML-KEM-768’s, the security level Chrome and Cloudflare use, runs around 1,184 bytes according to the FIPS 203 specification, almost 37 times larger. The ciphertext the server returns adds another 1,088 bytes. In a normal TLS 1.3 handshake this doesn’t add an extra network round trip (the key still travels in the handshake’s first and second messages), but it does inflate the size of those packets, which matters more on low-bandwidth links or embedded devices with limited RAM for holding handshake state.
| Option | When to use it | Advantage | Limitation |
|---|---|---|---|
| X25519 (classical) | Connections where long-term quantum risk isn’t a priority | 32-byte keys, very fast | Vulnerable to harvest now, decrypt later if a quantum computer appears |
| Pure ML-KEM-768 | Environments requiring full quantum resistance, without relying on ECC | Secure against Shor’s algorithm | Less public analysis history than ECC; a flaw in the lattice breaks everything |
| X25519MLKEM768 (hybrid) | Today’s recommended standard in TLS 1.3, used by Chrome and Cloudflare | Both algorithms must be broken at once | Heavier handshake messages than with a single algorithm |
💭 Key point: ML-KEM’s goal isn’t to protect you from a quantum computer that exists today: it’s to prevent traffic someone records now from being decrypted ten or fifteen years from now.
How to test it
Confirming whether a connection already negotiates a post-quantum group takes one command. With an OpenSSL 3.2 or higher build (or the oqs-provider if your OpenSSL doesn’t ship with it), you can force the group and read what the server responded:
openssl s_client -connect www.cloudflare.com:443 -tls1_3 -groups X25519MLKEM768 < /dev/null 2>/dev/null | grep "Negotiated TLS1.3 group"If the server supports it, the output shows Negotiated TLS1.3 group: X25519MLKEM768. To check on your own server side with nginx on OpenSSL 3.2+, it’s enough to declare the group in the TLS configuration:
ssl_protocols TLSv1.3;
ssl_conf_command Groups X25519MLKEM768:X25519;With that line, nginx offers the hybrid group first and falls back to pure X25519 if the client doesn’t support it. For the other end of the stack, SSH, it’s enough to list the key exchange algorithms your OpenSSH 9.9 or higher build supports:
ssh -Q kex | grep -i mlkemIf mlkem768x25519-sha256 appears in the list, your outgoing SSH connections can already negotiate the same kind of hybrid scheme the web uses.
Impact and analysis
Key exchange is the easy part to migrate: it changes with every new connection and doesn’t depend on a prior chain of trust. Digital signatures are a different story. A TLS certificate today is signed with RSA or ECDSA, and migrating that to a post-quantum algorithm like Dilithium means changing the entire chain of trust (certificate authority, client, server) at the same time, with certificates much heavier than current ones. That’s why Chrome, Cloudflare, Signal, and Apple started with key exchange: it’s the piece with the most urgency (due to the risk of recording traffic today) and the one that generates the least compatibility friction.
The real limitation is that asymmetry. Today your HTTPS traffic can travel with a quantum-resistant session key, but the certificate identifying the server is still signed with an algorithm Shor’s algorithm would break if the right machine existed. That doesn’t compromise retroactive confidentiality (ML-KEM’s goal), but it does leave the door open for someone to forge a server’s identity in a quantum future. Signature migration comes next, and it’s the slowest and most costly part of the process.
What’s next
NIST has also already published the post-quantum signature standards: FIPS 204 (ML-DSA, derived from Dilithium) and FIPS 205 (SLH-DSA, derived from SPHINCS+), both on that same August 13, 2024, alongside FIPS 203. Adopting those two will take longer because it touches certificate authorities, the browser ecosystem, and every client that validates certificates. In the meantime, hybrid key exchange will likely become the default in more protocols beyond TLS and SSH: VPNs, enterprise messaging, and any channel where recording traffic today would have value a decade from now.
📖 Summary on Telegram: View summary
Try it yourself: run openssl s_client -connect www.cloudflare.com:443 -groups X25519MLKEM768 against any site behind Cloudflare and see if your connection already negotiates the hybrid group.
Frequently Asked Questions
What is ML-KEM and how does it differ from Kyber?
ML-KEM is the final name NIST gave the Kyber algorithm when it standardized it as FIPS 203 in August 2024. The mathematical design is the same (a lattice-based key encapsulation mechanism), but the final standard adjusted encoding details compared to the Kyber versions that circulated as drafts.
Why use a hybrid scheme instead of pure post-quantum?
Because ML-KEM is a relatively new algorithm, with fewer years of public cryptanalysis than X25519. Combining both means an attacker has to break them both at once, so a future flaw in either algorithm alone doesn’t compromise the connection by itself.
Is my connection already protected against quantum computers?
If you’re using a recent version of Chrome against a server that supports X25519MLKEM768 (like those behind Cloudflare), yes, at least for the key exchange. The server’s certificate, on the other hand, is still usually signed with a classical algorithm.
What is harvest now, decrypt later?
It’s the strategy of recording encrypted traffic today, even though it can’t be decrypted yet, to store it and decrypt it once a quantum computer capable of breaking RSA or ECC exists. It’s the concrete threat that justifies migrating encryption now, not once that machine exists.
When will certificates and digital signatures be updated to post-quantum?
NIST already published the signature standards (FIPS 204 and FIPS 205) the same day as ML-KEM, but migrating certificates requires coordinating certificate authorities, browsers, and clients all at once, so that process moves more slowly than key exchange did.
Do I need to do anything as a developer?
If you administer a server with OpenSSL 3.2+ or a recent version of nginx, enabling the X25519MLKEM768 group in the TLS configuration is enough. For SSH, updating to OpenSSH 9.9 or higher already gives you the hybrid exchange available.
References
- NIST FIPS 203: the official ML-KEM standard, published August 13, 2024.
- Signal, PQXDH announcement: Signal’s post-quantum key agreement protocol, from September 19, 2023.
- Apple Security, PQ3 for iMessage: technical detail of the hybrid scheme Apple integrated starting with iOS 17.4.
- Chromium Blog: announcement of hybrid support with Kyber in Chrome, August 2023.
- Cloudflare Radar: live data on post-quantum encryption adoption in the traffic Cloudflare handles.
- OpenSSH release notes: version history, including 9.0 with post-quantum key exchange enabled by default.
📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Markus Winkler en Unsplash
0 Comments