The attacker does not need to break anything today. Recording and storing is enough; the decryption waits for the hardware. Data with a long shelf life is the target.
The danger is not that quantum computers can read your traffic now. It is that what you send now can be kept and read once they can. So the fix has to be in place before the threat arrives, not after.
What a quantum computer actually breaks
Not everything. The encryption that scrambles the actual data, symmetric ciphers like AES, only gets weakened by quantum computers, not broken; doubling the key size restores the margin, and AES-256 is already there. Hash functions are in the same position.
The weak point is the step that happens first: the key exchange. Before any data flows, your browser and the server have to agree on a shared secret key, even though they have never met and everyone on the network can watch them do it. They pull this off with some clever public-key math, today usually a method called X25519.
Here is the plain-language version. Imagine two people in a crowded room agreeing on a secret number out loud, using a trick so that no one listening can work out the number. Today's trick is easy to perform but, for a normal computer, practically impossible to reverse. A quantum computer, running something called Shor's algorithm, happens to be very good at reversing exactly this kind of trick. Recover that secret number from a recording and the whole conversation unlocks, no matter how strong the encryption around the data was.
The hybrid group folds a classical and a post-quantum exchange into a single secret. Either one alone keeps the session safe.
ML-KEM, and why it runs alongside the old way
The replacement for the vulnerable key exchange is ML-KEM (Module-Lattice Key Encapsulation Mechanism, standardised as FIPS 203, and grown out of the algorithm previously called Kyber). Its security rests on lattice problems that no known quantum algorithm solves efficiently. The common strength for the web is ML-KEM-768.
But new cryptography is rarely deployed alone. Browsers and servers pair it with the classical X25519 in a hybrid exchange, named X25519MLKEM768. The reasoning is caution: if a flaw is later found in the young post-quantum algorithm, the proven classical half still protects you, and if a quantum computer arrives, the post-quantum half does. An attacker has to break both, so the hybrid is never weaker than what you already trusted. During this transition, hybrid is the sensible default, and it is what modern Chrome, Firefox and Edge now negotiate automatically.
Classical, post-quantum, hybrid
| Key exchange | Stops today's attacker | Stops a future quantum attacker | Notes |
|---|---|---|---|
| X25519 (classical) | Yes | No | Proven and fast, but breakable by Shor's algorithm |
| ML-KEM-768 alone | Yes | Yes | Strong, but the algorithm is young |
| X25519MLKEM768 (hybrid) | Yes | Yes | Safe unless both are broken; the current default |
This only concerns how the session key is agreed. The data itself is still protected by AES, which a quantum computer cannot break at 256-bit strength.
What it protects, and what it does not yet
Post-quantum key exchange protects confidentiality over time: the session key cannot be recovered from a recording, so traffic captured today stays unreadable even against a future quantum computer. That is the whole point of closing the harvest-now-decrypt-later window.
What it does not change yet is authentication. The certificate that proves you are talking to the real server is still signed with classical algorithms (ECDSA or RSA). Migrating those to post-quantum signatures is a separate, slower effort. The reassuring part is that a signature only has to hold at the moment of the handshake: an attacker cannot record a connection now and forge the certificate later, so there is no harvest-now-decrypt-later risk there. The urgent half, confidentiality, is the half hybrid key exchange already covers.
Why a DNS resolver cares
DNS is a record of where you go. Each query names a site you are about to visit, and that history has a long shelf life: it is exactly the kind of low-volume, high-value data worth storing now to read later. Encrypted DNS already hides those queries on the wire; post-quantum key exchange keeps them hidden even if the recording outlives today's cryptography.
dnsdoh.art offers X25519MLKEM768 on its encrypted-DNS endpoint, so a current browser gets post-quantum protection on its lookups automatically, with a clean fallback for older clients. It pairs with Encrypted Client Hello, which hides the site name in the handshake; together they harden the parts of a connection that ordinary encryption leaves exposed. If you have not encrypted your DNS yet, start with the setup guide, and the protocols comparison covers the options.
Encrypt your DNS, quantum-ready
A current browser pointed at an encrypted-DNS endpoint that supports it gets post-quantum key exchange with nothing to configure. Start here.
Encrypt your DNS