Short answer: In one SSRN benchmark of TLS 1.3 handshakes, hybrid X25519MLKEM768 key exchange raised median latency from 0.666 ms to 0.877 ms and the ClientHello from 188 to 1,364 bytes, while ML-DSA-65 certificates had the larger effect on latency and server CPU. A separate arXiv study found the key exchange algorithm had a negligible effect on handshake latency in its setup. Both are controlled lab measurements, not Internet-wide figures.

Two separate problems

The SSRN paper says post-quantum migration in TLS poses two engineering problems: replacing classical key exchange with a quantum-resistant or hybrid mechanism, and replacing classical certificate authentication with post-quantum signatures. It benchmarks them separately and together using TLS 1.3 configurations based on X25519, X25519MLKEM768, ECDSA P-256 and ML-DSA-65, with 300 fresh handshakes per configuration.

Results from the SSRN benchmark

The paper reports median latency of 0.66595 ms for X25519 with ECDSA. With hybrid X25519MLKEM768 key exchange it was 0.87666 ms (31.6 percent higher), with ML-DSA-65 authentication 1.52414 ms (128.9 percent higher), and with both 1.62282 ms (143.7 percent higher). The hybrid key exchange raised the ClientHello from 188 to 1,364 bytes, and the ML-DSA-65 certificate measured 5,521 bytes against 396 bytes for ECDSA P-256. The authors conclude that in this benchmark ML-DSA authentication produced the larger latency and server-CPU effect, while hybrid key exchange produced the clearest first-flight size increase. They state the study is limited to the evaluated configurations and a controlled environment and does not claim universal Internet or production performance.

A different result

An arXiv study from 2026 reports that the TLS handshake layer is effectively algorithm-neutral. In its setup, classical, hybrid and pure ML-KEM configurations all show negligible effect sizes, with no practically meaningful penalty or advantage attributable to the key exchange algorithm, which it says is consistent with earlier work. It records the ClientHello and ServerHello lengths and the key_share payload size, noting that the payload size is fixed by the algorithm specification. Its tables list handshake times in milliseconds for combinations such as x25519, x25519_MLKEM768 and MLKEM1024 at 4 KB and 40 KB payloads. The text we reviewed notes that hybrid configurations add some delay between the TLS handshake finishing and the first HTTP request, but we do not reproduce those numbers as a general rule.

Measurement setups differ

A third paper, in a Future Generation Computer Systems journal, describes a test framework using OpenSSL with the Open Quantum Safe oqsprovider and liboqs 0.12.0. It measures handshakes completed in 10 seconds, repeating each configuration 50 times, and the kilobytes transmitted per handshake. It also notes the KEMTLS proposal, which uses KEMs for server authentication to reduce the overhead of post-quantum signatures, and says that proposal had not been standardized, which raises compatibility concerns.

What this does not tell you

The studies use different setups, so their numbers cannot be compared directly. None of them measures real Internet conditions, and the figures above are not a prediction for any production service.

FAQ

Does hybrid ML-KEM slow down TLS?

One benchmark found median latency rose about 31.6 percent in a local setup, while another found a negligible effect. The setups differ.

What gets bigger?

In the SSRN benchmark, the ClientHello went from 188 to 1,364 bytes with X25519MLKEM768, and the ML-DSA-65 certificate was 5,521 bytes against 396 for ECDSA P-256.

Which costs more, key exchange or signatures?

In the SSRN benchmark, ML-DSA-65 authentication had the larger latency and server-CPU effect.

What is KEMTLS?

A proposal using KEMs for server authentication to reduce signature overhead. One paper notes it had not been standardized.

Are these production numbers?

No. The SSRN authors say they do not claim universal Internet or production performance.

All field notes