Every HTTPS connection rests on two pieces of asymmetric cryptography: a key agreement that derives the session secret, and a digital signature that proves the server is who it claims to be. Both are broken (in principle, today) by Shor’s algorithm running on a sufficiently large quantum computer. The migration to post-quantum HTTPS is now well underway for key agreement, and barely beginning for authentication. Those two halves are not on the same clock, and understanding why is the whole story.
What a Quantum Adversary Actually Breaks
The TLS 1.3 handshake combines an ephemeral key exchange (typically X25519, an elliptic-curve Diffie–Hellman variant) with a server signature over the transcript (RSA, ECDSA, or Ed25519). The server’s identity is in turn vouched for by an X.509 certificate chain, which is itself a sequence of signatures terminating at a root in the client’s trust store.
Shor’s algorithm factors integers in polynomial time, , and solves the discrete logarithm problem on elliptic curves with the same asymptotic. That destroys RSA, DH, ECDH, ECDSA, and Ed25519 simultaneously. Grover’s algorithm, by contrast, only gives a quadratic speed-up against symmetric primitives, so AES-256 and SHA-384 remain comfortable.
So the threat model for HTTPS is narrow but total: the entire asymmetric layer must be replaced, while the symmetric layer can stay.
Two Migrations, Not One
This is the single most important framing in the post-quantum HTTPS conversation, and it comes directly from the teams shipping the changes. Chrome’s cryptography leads put it this way:
“An adversary could store encrypted traffic now, wait for a CRQC to be practical, and then use it to decrypt the traffic after the fact.” — Adrian, Beck, Benjamin, O’Brien, Advancing Our Amazing Bet on Asymmetric Cryptography, Google, May 2024.
That attack, harvest now, decrypt later, is the reason key agreement migration cannot wait. Signed traffic is recorded today; the quantum computer only has to exist eventually.
Authentication has the opposite property. A forged signature is only useful while the attacker is online. Until a cryptographically relevant quantum computer (CRQC) physically exists, no one is forging anything. As Cloudflare put it:
“Organizations face two separate post-quantum migrations: key agreement is urgent; signatures are much more complex but less time-critical.” — Westerbaan, The State of the Post-Quantum Internet, Cloudflare, March 2024.
So the industry is shipping key agreement first and aggressively, and authentication second and cautiously.
The New Building Blocks
NIST finalised three standards in August 2024. A fourth is in draft.
| Standard | Algorithm | Purpose | Underlying Hard Problem |
|---|---|---|---|
| FIPS 203 | ML-KEM (Kyber) | Key encapsulation | Module-LWE on lattices |
| FIPS 204 | ML-DSA (Dilithium) | Signatures | Module-LWE / Module-SIS |
| FIPS 205 | SLH-DSA (SPHINCS+) | Signatures (stateless hash-based) | Hash function security |
| Draft | FN-DSA (Falcon) | Signatures (compact) | NTRU lattices |
NIST also selected HQC as a code-based backup KEM in March 2025, hedging against a potential break in lattice assumptions.
The relevant key and signature sizes are the source of every operational problem that follows:
| Algorithm | Public Key | Signature / Ciphertext |
|---|---|---|
| X25519 | 32 B | 32 B |
| Ed25519 | 32 B | 64 B |
| ECDSA P-256 | 64 B | ~70 B |
| RSA-2048 | 256 B | 256 B |
| ML-KEM-768 | 1,184 B | 1,088 B |
| ML-DSA-44 | 1,312 B | 2,420 B |
| SLH-DSA-128s | 32 B | 7,856 B |
| FN-DSA-512 | 897 B | 666 B |
Lattice-based KEMs are workable. Lattice-based signatures are awkward. Hash-based signatures are large. Compact signatures (Falcon) require floating-point arithmetic to sign, which is a class of constant-time-implementation nightmare.
Hybrid Key Agreement Is Already the Default
The TLS deployment for key agreement is a hybrid: a classical curve and a post-quantum KEM running in parallel, with the session secret derived from both:
If either primitive holds, the session holds. The standardised codepoint is X25519MLKEM768 (0x11EC in TLS), replacing the earlier experimental X25519Kyber768Draft00 (0x6399), a change made necessary because the final ML-KEM standard is wire-incompatible with the draft Kyber it was based on.
The deployment numbers are striking. Per Cloudflare’s 2025 report:
“Over half of human-initiated traffic with Cloudflare is protected against harvest-now/decrypt-later with post-quantum encryption.” — Westerbaan, State of the Post-Quantum Internet in 2025, Cloudflare, October 2025.
Chrome enabled ML-KEM hybrid key agreement by default in version 124 on desktop and reported a median handshake latency increase of 4%, non-zero but small enough to ship. ML-KEM adds roughly 1.1–1.2 kB to the ClientHello and ServerHello. That is the only price for harvest-now/decrypt-later immunity, and it is paid.
The Hard Part: Certificates
Where the key-agreement migration is essentially done, the certificate migration has not yet started in production. The arithmetic explains why.
A modern TLS handshake includes a leaf certificate, one or two intermediate certificates, two signed certificate timestamps (SCTs) for Certificate Transparency, and a signature over the handshake transcript. Today the median chain is around 3.2 kB. With ML-DSA-44 signatures, naïvely:
- two SCTs and a leaf signature alone add 7,260 bytes of authentication overhead;
- a full hybrid chain (classical + post-quantum signatures) pushes total handshake size past 15 kB.
That number matters because there is a well-documented performance cliff:
“Some clients or middleboxes don’t like certificate chains larger than 10 kB. Crossing that threshold triggers extra round-trips, causing 60%+ slowdown.” — Cloudflare, 2021 PQ TLS experiment, restated in State of the Post-Quantum Internet, 2024.
This is the protocol-ossification problem in concrete form. TCP’s initial congestion window, QUIC’s anti-amplification limit, middlebox MTU assumptions, ASN.1 buffer sizes in legacy stacks; every single layer has informally absorbed the assumption that a TLS handshake is small.
The Way Out: Merkle Tree Certificates
The most promising structural answer is Merkle Tree Certificates (MTC), an IETF draft from a joint Google/Cloudflare/Apple/Geomys team in the PLANTS working group:
“ML-DSA-44 uses 1,312 bytes per public key and 2,420 bytes per signature. Two SCTs and a leaf signature add 7,260 bytes of authentication overhead. Merkle Tree certificates are significantly smaller than a single ML-DSA-44 signature, and almost ten times smaller than the three signatures necessary to include post-quantum SCTs.” — Benjamin, O’Brien, Westerbaan, Valenta, Valsorda, draft-ietf-plants-merkle-tree-certs.
The idea inverts the traditional chain. Instead of every leaf carrying a signature, the CA maintains an append-only log, periodically signs a Merkle root over the log’s current contents, and gives each subscriber an inclusion proof, a logarithmic-size authentication path from leaf to root.
For a CA issuing certificates, the proof is roughly bytes, and the expensive ML-DSA signature exists only once, on the root. Per the same draft, this brings authentication payload below 800 bytes per connection, smaller than today’s RSA chains.
The tradeoffs are real: clients must hold predistributed Merkle roots, certificates only become usable after the next landmark is signed (so there is an issuance delay), and the system requires log infrastructure beyond what Certificate Transparency provides today. But MTC is the only proposal that simultaneously achieves post-quantum security, Certificate Transparency, and reasonable wire size.
Where the Migration Stands
| Surface | Status (mid-2026) |
|---|---|
| Symmetric crypto (AES, SHA-2/3) | No change needed |
| TLS key agreement (X25519MLKEM768) | Default in Chrome, Firefox, Cloudflare edge; >50% of Cloudflare human traffic |
| Origin-side key agreement | ~3.7% of origins (2025) |
| TLS authentication (PQ certificates) | Drafting; first test certificates expected 2026–2027 |
| CA root migration | Not started in public PKI |
| OCSP / revocation in PQ world | Open problem |
| Middlebox / appliance compatibility | Untested at scale |
The regulatory clock varies: NSA’s CNSA 2.0 mandates post-quantum for U.S. national security systems by 2033; the EU and UK guidance targets 2030–2035 for sensitive sectors. None of those deadlines work without a certificate solution shipped years earlier.
The Quiet Part
The reason this migration is hard is not the mathematics. ML-KEM and ML-DSA are mature, peer-reviewed primitives, and the implementations are open. The reason it is hard is that HTTPS is a sixty-layer cake: a TLS handshake touches a CA, a CT log, an OCSP responder, a browser trust store, a kernel TCP stack, a load balancer, an HSM, an MTU-fixed middlebox, and an ASN.1 parser written in 2003. Every one of them has an opinion about how big a certificate may be.
Switching the algorithms is the easy part. Resizing the cake without dropping it is the hard part.
“Cryptography is rarely broken; it is bypassed.” — Adi Shamir
That, more than any qubit count, is what determines whether HTTPS survives the transition gracefully.
References
- Westerbaan, B. State of the Post-Quantum Internet in 2025. Cloudflare, October 2025. blog.cloudflare.com/pq-2025
- Westerbaan, B. The State of the Post-Quantum Internet. Cloudflare, March 2024. blog.cloudflare.com/pq-2024
- Adrian, D.; Beck, B.; Benjamin, D.; O’Brien, D. Advancing Our Amazing Bet on Asymmetric Cryptography. Google / Chromium, May 2024. blog.google/chromium/advancing-our-amazing-bet-on-asymmetric
- Benjamin, D.; O’Brien, D.; Westerbaan, B.; Valenta, L.; Valsorda, F. Merkle Tree Certificates. IETF draft-ietf-plants-merkle-tree-certs. datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs
- NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. August 2024. csrc.nist.gov/pubs/fips/203/final
- NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard. August 2024.
- NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard. August 2024.
- Cloudflare. Post-quantum cryptography (PQC) — SSL/TLS docs. developers.cloudflare.com/ssl/post-quantum-cryptography