Your Browser Already Went Quantum-Safe: How Hybrid X25519 and ML-KEM Are Rolling Out

Your browser has probably been doing post-quantum cryptography for months, and you never clicked a thing. When you load a page in a recent Chrome, Firefox, or Safari, it negotiates a session key using two algorithms at once: X25519, the elliptic-curve exchange you have trusted for years, and ML-KEM, the lattice-based scheme NIST standardized in 2024. Nobody sent out a banner. The switch just happened, mostly while you were reading something else.

Before you read: The NIST standards and the ‘store now, decrypt later’ threat are covered in The Quantum Time Bomb: Why NIST’s New Encryption Standards Can’t Wait. This piece looks at what those standards look like in production, which is messier and more interesting.

Table of contents

• Why Pair Two Algorithms Instead of Picking the Best One
• The Shipping Spree of 2024 and 2025
• The Packet That Broke Your Firewall
• What Hybrid Doesn’t Protect
• Sources

Why Pair Two Algorithms Instead of Picking the Best One

The logic is insurance in both directions. If a quantum computer eventually breaks X25519, ML-KEM still protects the session. If ML-KEM turns out to have a flaw nobody has found yet, X25519 still holds the line. An attacker has to beat both. Think of a bank vault that needs two different keys held by two different people. That matters because ML-KEM is young: it has had a few years of public scrutiny, while X25519 has had over a decade.

The idea is not new. In 2016, Google and Cloudflare ran an experiment called CECPQ1, pairing X25519 with a lattice scheme called New Hope, and measured what happened to real traffic. It proved the concept and then sat on a shelf while the standards bodies finished their homework.

The Shipping Spree of 2024 and 2025

The timeline moved faster than most people expected. Chrome 124 enabled a hybrid called X25519Kyber768 in April 2024, then switched to the finalized X25519MLKEM768 in Chrome 131 that November. Firefox followed later in 2024. By spring 2025, Cloudflare reported that roughly 38% of the human HTTPS traffic it handled was negotiated with post-quantum key agreement.

Then the server and OS side caught up. OpenSSL 3.5 landed in April 2025 with ML-KEM and the hybrid built in. OpenSSH 10.0 made mlkem768x25519-sha256 its default key exchange the same spring. Apple added hybrid post-quantum TLS to iOS 26 and macOS 26. Signal had gone further back, shipping its PQXDH handshake in 2023, before most of the web had heard the phrase.

Did you know that the TLS identifier for the hybrid group is 0x11EC, which is 4588 in decimal? A boring number for a feature that will decide how the web survives the next decade.

The Packet That Broke Your Firewall

Here is the part that never makes the press release. The hybrid client key share is 1,216 bytes: 1,184 for the ML-KEM-768 public key and 32 for X25519. Add the rest of a modern ClientHello and the first message of a TLS handshake now stretches across multiple TCP segments instead of fitting in one.

Did you know a standard ClientHello used to fit comfortably inside a single 1,500-byte Ethernet frame? The hybrid share alone eats most of that budget now.

That sounds trivial until you remember who sits in the middle of the network. Enterprise firewalls, older load balancers, and deep packet inspection appliances were written on the assumption that a ClientHello is small and arrives whole. Some of them drop, reset, or silently mangle what they don’t understand. Every corporate network has one appliance nobody has rebooted since the Obama administration, and it now decides whether your quantum defense works at all.

This is why the rollout looked like a staircase: ship, measure the breakage, fall back, fix, ship again. Browsers and servers handled it by retrying with classical key exchange when the hybrid failed. That keeps the web working, but it also means an attacker who can block the big packet can, in principle, force that fallback.

What Hybrid Doesn’t Protect

This is where I think the marketing gets ahead of the math. Hybrid key exchange protects the confidentiality of sessions recorded today. It does nothing for the certificates that authenticate the server. Those still rely on RSA and ECDSA signatures, which a future quantum computer could forge. The threat to certificates is impersonation at the moment an attacker has the machine, not data already vacuumed up, so the deadline is different and arguably later.

My honest take: shipping hybrid key exchange was the right call, and the browser teams deserve credit for doing it before anyone forced them. But ‘quantum-safe’ on a vendor landing page describes a session key, not the whole stack. The post-quantum signature migration is the harder job, and it has barely started.

Sources

• NIST FIPS 203 (ML-KEM), August 2024
• IETF draft-ietf-tls-ecdhe-mlkem (hybrid X25519MLKEM768 for TLS 1.3)
• Google Chrome Blog and Chrome release notes for Chrome 124 and Chrome 131 (2024)
• Cloudflare Blog and Cloudflare Radar post-quantum adoption statistics (2025)
• Adam Langley, CECPQ1 experiment write-up (2016)
• OpenSSL 3.5 release announcement (2025)
• OpenSSH 10.0 release notes (2025)
• Apple WWDC25 platform announcements (iOS 26, macOS 26)
• Signal Blog: PQXDH specification (2023)