The latency cost of post-quantum TLS, measured over 1.2 million handshakes

The case against enabling post-quantum key exchange by default has always been about cost. The keys are larger, the ClientHello is bigger, the computation is heavier, and — the argument goes — users will notice. We shipped it on by default in the alpha specifically so we could find out whether that is true.

Between February and June 2026 we collected timing telemetry from 1.24 million TLS handshakes across our alpha population. Because Dart sends no telemetry by default, this data comes exclusively from testers who explicitly opted into the measurement programme, and it contains handshake timings and network class only — no hostnames, no addresses, no content. That constraint shaped the study and it also limits it, which we come back to at the end.

The headline number is small

Median handshake latency for the hybrid construction was 81.4 ms against 74.6 ms for classical X25519 — a difference of 6.8 ms, or about 9%. For context, the interquartile range of handshake latency on residential Wi-Fi in the same dataset was 41 ms. The post-quantum penalty is, for most users on most connections, considerably smaller than the noise introduced by walking to another room.

Breaking the data down by network class shows the penalty is roughly constant in absolute terms rather than proportional. On fibre, where a classical handshake completes in 31 ms, the additional 6 ms is a 19% increase. On a congested mobile connection at 210 ms, the same 7 ms is lost entirely in the noise. This is the opposite of the pattern people intuitively expect, and it means the users most likely to perceive post-quantum overhead are the ones on the best connections.

The real cost is a packet-size problem, not a maths problem

Only about 1.1 ms of the median penalty is computation. ML-KEM-768 encapsulation and decapsulation are fast — faster, in fact, than the X25519 scalar multiplication they accompany on most of the hardware we sampled. The remaining cost comes from size.

A classical ClientHello fits comfortably in a single packet. A hybrid one is 1,637 bytes, which exceeds the common 1,500-byte Ethernet MTU and therefore spans two packets. For most connections this costs nothing measurable. For connections where the initial congestion window is small, or where a middlebox handles the second packet poorly, it costs an entire additional round trip.

The average is fine. A specific 3.1% of connections have a genuinely bad time, and reporting only the median would hide them. Both numbers belong in the summary.

This is where we think the public discussion has been imprecise. The claim “post-quantum TLS costs about 9%” is true of the median and misleading about the tail. For the 3.1% of connections that incur an extra round trip, the penalty was a median of 94 ms — more than doubling handshake time. Those users are concentrated on satellite links, some corporate networks with aggressive middleboxes, and older mobile infrastructure. They are a minority, they are not randomly distributed, and an average hides them completely.

Why we still ship it on by default

The threat model is what settles this. Harvest-now-decrypt-later attacks do not require a quantum computer to exist today; they require an adversary willing to store ciphertext until one does. Traffic captured in 2026 and decrypted in 2034 is still disclosed. For data with a long confidentiality lifetime — legal correspondence, medical records, source code, journalism — the correct comparison is not 7 ms against zero. It is 7 ms against the cost of that disclosure.

We also think the tail problem is fixable rather than fundamental. Most of it is congestion-window behaviour that improves as TLS 1.3 stacks and middleboxes catch up with larger ClientHellos, and some of it is already addressed by the ongoing work on key-share prediction. We would rather ship it, measure the tail, and report it honestly than wait for a version with no tail at all.

Method and limitations

Timings were captured client-side using the browser's internal network stack instrumentation, from the first byte of ClientHello to the completion of the handshake. Network class was inferred from the interface type and a bandwidth estimate, not from any address. Participants opted in explicitly and could inspect the exact payload before it was sent.

The most important limitation is selection bias, and it is severe. Testers who opt into a measurement programme run by a privacy-focused browser are not a random sample of internet users; they skew technical, well-connected, and geographically concentrated in North America and Western Europe. We have almost no data from regions where the tail problem is likely to be worst. Treat the 3.1% figure as a floor rather than an estimate.

Aggregated handshake timings are published quarterly at dartbrowser.com/research. If you operate network infrastructure in an under-represented region and would be willing to run a measurement client, we would like to hear from you: research@dartbrowser.com.

Related work

The performance of post-quantum key exchange in TLS has been measured before, most visibly by browser and CDN operators running large-scale experiments [6, 7]. Those studies report from the server side of a very large sample and are authoritative on aggregate cost. They are necessarily less informative about the tail, because a server operator sees connections that completed. Our sample is far smaller and heavily self-selected, but it is client-side and therefore includes the connections that struggled. We read the two sets of results as complementary rather than competing: the medians agree closely, and our contribution is a client-side view of who pays the additional round trip.

Artefacts

Everything below is published or available on request. A number nobody can reproduce is an advertisement, not a result.

References

1. National Institute of Standards and Technology (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard.
2. National Institute of Standards and Technology (2024). FIPS 204: Module-Lattice-Based Digital Signature Standard.
3. Rescorla, E. (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. IETF.
4. Stebila, D., Fluhrer, S., & Gueron, S. Hybrid key exchange in TLS 1.3. IETF, draft-ietf-tls-hybrid-design.
5. Bernstein, D. J., & Lange, T. (2017). Post-quantum cryptography. Nature, 549.
6. Langley, A. (2018–2019). CECPQ2 and experiments with post-quantum key agreement. Google.
7. Westerbaan, B., et al. (2024). The state of the post-quantum Internet. Cloudflare.