The cost of a quantum-safe web
The cost of a quantum-safe web
Cryptographic migration can be hard, but well-designed protocols built around crypto-agility make the transition graceful. Many users may not even have noticed that every major browser now offers a quantum-safe key exchange on every HTTPS connection, while only half of the top million websites accept it.
In our previous post, we explained why harvest-now-decrypt-later attacks put key exchange first in line for post-quantum cryptography. Traffic recorded today can be decrypted once a cryptographically relevant quantum computer exists, so data that must stay secret for years is already exposed. TLS secures nearly everything online, and it’s one of the first protocols to go post-quantum at scale. It’s one of the largest cryptographic migrations underway, and the best production evidence we have of what post-quantum cryptography costs.
Where the quantum risk sits in TLS
TLS provides different types of protection for web traffic. It authenticates the parties, proving the site you open really comes from your bank, and encrypts the traffic, so your network provider doesn’t see the password you enter. This post is about the encryption side. Authentication and the imminent move from X.509 to Merkle Tree Certificates (MTCs) will be covered in a future post.
TLS encryption works in two steps. Client and server first agree on a shared secret, then use it to encrypt everything with a symmetric cipher such as AES. The symmetric encryption is already safe against quantum attacks. But the key exchange isn’t. That’s the one a quantum computer breaks.
We focused on TLS 1.3, the only version with a quantum-safe key exchange. The client starts with a ClientHello that proposes several key-exchange algorithms and attaches its half of the exchange for each. The server picks one, computes its own half and sends it back in a ServerHello. This design makes TLS crypto-agile. A server can add a post-quantum key exchange without breaking older clients. It picks the post-quantum option when a modern client offers it, and falls back to the classical one for legacy clients.
A hybrid key exchange
TLS key exchange has mostly run on elliptic-curve Diffie-Hellman over X25519 for years. It’s fast and its key shares are tiny, but it is not post-quantum secure. Its replacement is X25519MLKEM768, a hybrid construction that keeps X25519 and runs ML-KEM, the post-quantum key encapsulation standard NIST published in 2024, alongside it.
X25519 and ML-KEM each produce a shared secret, and TLS combines the two. The key exchange stays secure as long as either one holds. A quantum computer breaking X25519 isn’t enough, and neither is a future flaw in ML-KEM. This safety net costs almost nothing in compute. The price is in size, with key shares more than thirty times larger:
All modern browsers now support this key exchange. Firefox 132 enabled X25519MLKEM768 by default in October 2024, and Chrome 131 followed in November 2024. Edge, Brave and Opera inherit it from Chromium, and Apple turned it on in Safari with iOS 26 and macOS 26 in September 2025. As of September 2026, Cloudflare Radar shows roughly three quarters of Swiss human traffic to Cloudflare coming from clients that request a post-quantum key exchange.
Servers haven’t caught up. In Jan Schaumann’s September 2026 crawl, only half of the top million websites supported post-quantum key exchange. If you host your own websites, most of your visitors already ask for a quantum-safe key exchange. Whether they get one depends on your edge configuration.
What it costs
We measured real handshakes against a live HTTPS endpoint over TCP and QUIC, the two transports that carry HTTPS today. Client, server and network path stayed fixed. We only toggled the post-quantum group on each side, which gives four configurations. Reported sizes include everything up to the first application data, including the TCP handshake bytes where applicable:
- Classical. Neither side offers the hybrid group.
- Client only. The client proposes the hybrid group and the server doesn’t support it.
- Server only. The reverse.
- Both PQC. Both sides support X25519MLKEM768
TLS handshake size: ClientHello, ServerHello and the rest
Bytes are where PQC costs something. Full PQC grows the handshake by 2.6 KB on both transports, from 3.3 KB to 5.9 KB over TCP and from 4.4 KB to 7.0 KB over QUIC. Almost all of it sits in the two Hello messages, about 1.2 KB in the ClientHello and 1.1 KB in the ServerHello. QUIC handshakes are about 1 KB bigger than TCP ones in every configuration, PQC or not. QUIC saves a few bytes thanks to UDP’s lighter headers, but it loses more than that because it pads the client’s Initial packets to 1,200 bytes to prevent DDoS amplification attacks. Clients also apply GREASE, randomizing the ClientHello to keep middleboxes from assuming fixed bytes, so exact sizes vary slightly between connections.
When only one side supports PQC, the cost isn’t symmetric. A client that offers PQC to a classical server still sends its 1.2 KB key share for nothing, whereas a server that enables PQC doesn’t add a single byte for classical clients. Most of your visitors are already paying that toll on every connection and getting no protection for it. Enabling PQC on your server costs classical clients nothing and turns the bytes they already send into actual protection.
Put these extra kilobytes next to the rest of the connection. We recorded an afternoon of normal browsing and divided the total traffic by the number of handshakes. Our afternoon of browsing produced around 70 KB per handshake on average. The post-quantum overhead therefore accounts for less than 4% of the traffic.
TLS handshake time on a clean connection
On a clean connection, quantum-safe key exchange is close to free. Full PQC adds 0.4 ms over TCP and 0.9 ms over QUIC, less than the run-to-run spread of about 1.5 ms. When only one side supports the hybrid group, the two settle on X25519 and the handshake costs the same as before. CPU time doesn’t move either, on client or server. ML-KEM runs in tens of microseconds, about as fast as X25519. The real gap is between transports. QUIC finishes in about 23 ms against 44 ms for TCP, because it runs the transport and TLS handshakes together and saves a full round trip. TCP must complete its own handshake before TLS can even start.
The difference is more noticeable on a bad network. We replayed the same runs over a simulated degraded Wi-Fi connection, which roughly doubles every handshake. Full PQC now adds 6.4 ms over TCP (+8%) and 7.0 ms over QUIC (+16%). The cost comes from packets, not computation. The larger Hellos take a TCP handshake from 10 to 14 packets, and a QUIC handshake from 6 to about 9. Each extra packet gives delay and loss one more chance to stall the handshake. Even a PQC client talking to a classical server loses 4.3 ms over QUIC, because its larger ClientHello crosses the network whatever the server picks.
Authentication is still classical
Hybrid key exchange closes the harvest-now-decrypt-later gap. It doesn’t protect authentication, which still rests on classical signatures that a quantum computer can eventually forge. The difference is timing. A recorded handshake can be decrypted years later, while a signature can only be forged on a live connection. That’s why key exchange went first.
Merkle Tree Certificates (MTCs), from the IETF PLANTS working group, tackle the size of post-quantum signatures. Google and Cloudflare are wrapping up a live experiment that proved the approach works, and production follows next. Let’s Encrypt plans to issue MTCs in 2027, and Cloudflare is launching its own public CA to do the same from early 2027. We’ll cover MTCs and the future of the Web PKI in a dedicated post. Until they reach production, the key exchange is the half you control.
