In most threat models, the threat and the defence operate in the same time window. You patch the vulnerability before the attacker exploits it, or you don’t. Post-quantum cryptography breaks this symmetry in a way that makes it uniquely dangerous to defer: the harvest can happen now, the decrypt happens later, and by the time the later arrives, it’s too late to protect the data that was captured.
This is not a hypothetical. It is not a distant concern. The infrastructure to execute harvest-now-decrypt-later (HNDL) attacks already exists, and the evidence that it is being used is accumulating. Understanding the timeline and the implications for browser security is what motivated us to make post-quantum key exchange the default in Dart, not a flag you flip in about:config.
What the attack actually looks like
A HNDL attack has two phases separated by years or decades. In the first phase, an adversary records encrypted network traffic. This is passive surveillance: the adversary sits on a network tap, a compromised ISP, or a submarine cable intercept point and stores everything. The cost of storage has fallen to the point where this is economically viable at nation-state scale. The traffic is useless to the adversary today because they cannot break the encryption.
In the second phase, the adversary has access to a cryptographically-relevant quantum computer (CRQC) — one large and reliable enough to run Shor’s algorithm against RSA or elliptic-curve keys at practical scale. They replay the stored traffic through the quantum computer. The session keys, which were protected by key exchange algorithms that are broken by Shor’s, are recovered. The plaintext is exposed.
The gap between phase one and phase two could be five years, ten years, or fifteen. That is precisely the problem. If the data captured today has a sensitivity window longer than the gap, the attack succeeds retroactively. The data was protected; then it wasn’t.
Which data is at risk
Not all data has a long sensitivity window. If you’re shopping for shoes, the fact that an adversary might be able to read your TLS session in 2035 is not a material concern. But consider what a browser routinely carries:
Authentication credentials. Session tokens, SSO assertions, OAuth flows. If a session token captured today can be replayed (or if the credential it derived from can be recovered), the adversary may be able to impersonate the user years later — or use the credential as a stepping stone in a later intrusion.
Healthcare and financial data. A TLS session carrying lab results, insurance data, or banking transactions from 2025 could expose information that is sensitive in 2035. HIPAA and GDPR protections do not expire when the keys do.
Corporate communications and IP. M&A discussions, litigation strategy, product roadmaps. The sensitivity window for this class of data often exceeds a decade. Law firms, investment banks, and technology companies are the most exposed, which is exactly why they are targeted.
Government and diplomatic traffic. Classified or sensitive government traffic with classification windows of 10 to 25 years is precisely the class of data that HNDL was designed to capture. Intelligence agencies have been aware of this threat model for years.
The timeline problem
The US National Institute of Standards and Technology (NIST) finalised its first set of post-quantum cryptographic standards in August 2024: ML-KEM (CRYSTALS-Kyber) for key encapsulation and ML-DSA (CRYSTALS-Dilithium) for digital signatures. This was the result of an eight-year standardisation process. The standards are ready. The deployment is not.
The critical path for protecting against HNDL is not: “wait until quantum computers are close, then migrate.” By the time the threat is visible, the harvest window has already closed. The correct action is to migrate TLS key exchange to post-quantum algorithms now, so that traffic captured today cannot be decrypted even when a CRQC exists.
Most browsers have made tentative moves in this direction. Chrome enabled a hybrid X25519+Kyber key exchange as an experiment in 2023 and has since expanded it. Firefox followed. But in most cases these are enabled for connections to Google’s infrastructure, or for a fraction of connections, or as an experiment that can be toggled off. The default TLS handshake for most browser sessions is still purely classical.
Why the browser is the right place to act
The browser is where the largest volume of sensitive TLS traffic originates. It is also where the user has the least visibility into what cryptographic algorithms are being negotiated. When you connect to your bank, you do not know whether the session key was established with X25519 (broken by Shor’s) or ML-KEM-768 (not broken). You trust that the browser is doing the right thing.
Most browsers are not doing the right thing by default for most connections. They are doing the right thing for connections to their own infrastructure, and legacy TLS for everyone else. This is a conflict of interest masquerading as a compatibility trade-off.
Dart makes ML-KEM-768 the default for all new TLS sessions that the server supports, using a hybrid mode (X25519 + ML-KEM-768) for backwards compatibility with servers that do not yet support pure PQC. When both sides support ML-KEM-768 alone, Dart uses it. The goal is to ensure that no session key established through Dart today is recoverable by a future quantum adversary.
The server-side gap
A browser cannot negotiate a post-quantum key exchange unilaterally. The server must also support the algorithm. This is the current bottleneck: server-side PQC adoption is patchy. Major CDNs (Cloudflare, Fastly) and large platforms (Google, Amazon) have added ML-KEM support. Smaller operators have not.
In hybrid mode, Dart always sends the ML-KEM key share in the ClientHello. If the server acknowledges it, the session uses ML-KEM for key derivation. If the server ignores it, the session falls back to X25519. No compatibility is lost; the worst case is a classical session, which is the baseline today.
As server adoption increases, the fraction of Dart sessions using PQC key exchange rises automatically. Users do not need to do anything. The protection improves passively as the ecosystem migrates.
Identity keys are a separate problem
PQC key exchange protects session confidentiality. It does not protect the authentication layer. If your identity is asserted via an RSA or ECDSA signature (as in most TLS client certificates, FIDO2 assertions, and OAuth flows), that signature can be forged by a future quantum adversary — but only if the private key can be recovered.
This is where Dart’s hardware-bound identity layer becomes relevant to the post-quantum story. Private keys stored in a TPM or Secure Enclave cannot be exported, which means a quantum computer cannot be pointed at a copy of the key. The key material that protects your authentication never leaves the hardware chip, so there is nothing to harvest. The new identity keys Dart generates use ML-DSA (CRYSTALS-Dilithium) for signatures, completing the post-quantum picture for both confidentiality and authentication.
What you should do now
If you are a user: use a browser that defaults to PQC key exchange for all sessions, not just Google’s. Check that your identity keys are hardware-bound. Understand that any sensitive traffic you sent over classical TLS in the last several years may be in someone’s archive waiting for a quantum computer.
If you are running a server: enable ML-KEM support in your TLS stack. Nginx supports it via BoringSSL or a patched OpenSSL build. Caddy and Envoy have PQC support in recent versions. Your CDN almost certainly supports it already — enable it. The performance overhead is modest and the compatibility risk in hybrid mode is effectively zero.
If you are a security officer: the harvest-now phase of HNDL is already underway for high-value targets. Anything transmitted over classical TLS before your organisation migrates to PQC should be treated as potentially compromised once a CRQC becomes available. Adjust your data classification and retention policies accordingly.
The quantum computer does not exist yet. The attack is already running. The only window that matters is the one between now and when you migrate.
Technical note: Dart Browser implements ML-KEM-768 (CRYSTALS-Kyber, NIST FIPS 203) and ML-DSA-65 (CRYSTALS-Dilithium, NIST FIPS 204). Hybrid key exchange uses the concatenation KDF approach described in draft-ietf-tls-hybrid-design. Identity keys use ML-DSA-65 with hardware attestation via TPM 2.0 or Apple Secure Enclave. Questions: security@dartbrowser.com.