A large quantum computer capable of running Shor's algorithm against the key sizes used on the internet today does not exist. The reason to care about post-quantum cryptography now anyway has a name: harvest now, decrypt later. An adversary with the resources to record encrypted traffic at scale, whether a state intelligence service or anyone with equivalent capability, can store today's TLS-encrypted connections and simply wait. If a cryptographically relevant quantum computer arrives in ten or twenty years, everything encrypted with a purely classical key exchange today becomes readable retroactively. Data with a long shelf life, medical records, legal communications, anything meant to stay private for decades, is exposed by that timeline even though the attack hasn't happened yet.
Why Hybrid, Not Pure Post-Quantum
The obvious fix is to switch TLS to a post-quantum key exchange algorithm and be done with it. Nobody serious is doing that yet, for a good reason: post-quantum algorithms are mathematically newer and less battle-tested than the elliptic curve cryptography they'd replace. ML-KEM, the algorithm NIST standardized in FIPS 203 in 2024 based on the CRYSTALS-Kyber submission, is built on lattice problems that have had far less adversarial scrutiny than the discrete-log problem underlying X25519 and other elliptic curve systems used today.
The deployed answer is a hybrid key exchange: run the classical algorithm (typically X25519) and the post-quantum algorithm (ML-KEM) side by side in the same handshake, and combine both resulting secrets into the final session key. Breaking the connection then requires breaking both algorithms, not just one. If ML-KEM turns out to have an undiscovered flaw, X25519 still holds the line; if a quantum computer eventually breaks X25519, ML-KEM still holds it. Security only improves, and it can't get worse than the classical baseline.
A hybrid handshake isn't ML-KEM replacing X25519, it's both running in parallel and their outputs being mixed together with a key derivation function, so an attacker has to defeat both independently to recover the session key.
What's Actually Running Today
Chrome enabled a hybrid key exchange combining X25519 and Kyber768 (now standardized as X25519MLKEM768) by default in 2024, meaning a large share of HTTPS connections from Chrome to a supporting server already negotiate post-quantum protection without any user action. Cloudflare has offered post-quantum hybrid key exchange across its edge network since 2022 and expanded default support to a large share of the domains it fronts. The IETF's TLS working group has been standardizing the codepoints for this in draft-ietf-tls-hybrid-design, giving different implementations a shared way to signal support for the same combination.
Messaging protocols moved on a parallel track. Signal added PQXDH, a post-quantum extension to its X3DH initial key agreement, in 2023, combining X25519 with CRYSTALS-Kyber for the first message exchange that establishes a conversation. Apple shipped PQ3 for iMessage in 2024, a post-quantum ratchet built for the same harvest-now-decrypt-later threat, independent of the TLS work happening at the browser and CDN layer.
The Size Cost of a Bigger Public Key
Nothing about this is free. A Kyber768 public key runs around 1,184 bytes, against roughly 32 bytes for an X25519 public key, so a hybrid handshake sends noticeably more data than a classical one. For a single web connection this is invisible, an extra kilobyte or so on a handshake that's already exchanging certificates. At the scale of a CDN handling billions of connections, or on a constrained network, the overhead is a real engineering line item, which is part of why adoption has rolled out gradually by provider rather than flipping on everywhere at once.
| Component | Approximate public key size |
|---|---|
| X25519 (classical) | 32 bytes |
| ML-KEM / Kyber768 (post-quantum) | ~1,184 bytes |
SSH Got There First
TLS and messaging apps get the attention, but OpenSSH quietly made the same move earlier and with less fanfare. OpenSSH 9.0, released in 2022, changed its default key exchange method to sntrup761x25519-sha512, a hybrid combining X25519 with Streamlined NTRU Prime, a post-quantum algorithm distinct from ML-KEM but built on a related lattice-based approach. Anyone running a current OpenSSH client or server has likely been using a hybrid post-quantum key exchange for every session since, without any configuration change, years before Chrome's rollout made headlines. WireGuard-adjacent projects like Rosenpass have pursued a similar hybrid approach for VPN key establishment. The pattern across all of these deployments is consistent: post-quantum protection arriving as a default upgrade to existing infrastructure, layered on top of classical cryptography rather than replacing it.
What's Not Fixed Yet: Certificates and Signatures
Everything above is about key exchange, the part of the handshake that establishes a shared secret. It says nothing about the signatures inside TLS certificates, which still rely on classical algorithms like RSA and ECDSA almost everywhere. NIST has also standardized post-quantum signature algorithms, ML-DSA and SLH-DSA among them, but migrating the certificate ecosystem is a much larger undertaking: certificate authorities, browsers, and every piece of software that validates a certificate chain all need to agree on new formats before it can roll out safely. Harvest-now-decrypt-later mainly threatens confidentiality, which is why key exchange moved first; signature migration protects authenticity, on a slower and separate timeline.
What This Means for You Right Now
If you're running a recent version of Chrome or Firefox and connecting to a site fronted by a CDN that supports it, some of your web traffic is already hybrid-protected without any setting to find or toggle. There's nothing to configure and nothing to verify manually in normal browsing. The more useful question to ask about any service handling sensitive, long-lived data isn't whether it has "quantum-proof encryption," a phrase that should read as a marketing flag on its own, but whether it's tracking the actual standards timeline and has a credible plan for the parts, like certificate signatures, that haven't moved yet.
The Timeline Nobody Can Pin Down
Estimates for when a cryptographically relevant quantum computer might exist range widely, and every serious estimate carries the caveat that it's a projection, not a schedule. What's not speculative is the data being harvested right now for a future decryption attempt, and the multi-year lag between "we should migrate" and "the migration is actually deployed everywhere it needs to be." Certificate authorities, hardware security modules, embedded devices, and legacy systems all move slower than a browser vendor pushing an update. What the hybrid approach actually buys is time: it lets the slow parts of the ecosystem start moving now, on a timeline decoupled from actually knowing when the threat becomes real.