Quick answer: Moving TLS from classical to hybrid ML-KEM key exchange adds a measurable but generally small cost: AWS has published roughly 1,600 additional handshake bytes and 80 to 150 microseconds of extra computation moving from ECDH to an ECDH plus ML-KEM hybrid, overhead that is incurred once per connection and amortized across the session. The cost that actually matters varies by workload, growing more significant for high-frequency, short-lived connections than for persistent ones. This guide provides a lab test plan covering handshake latency, CPU and memory, packet fragmentation, retransmission, proxy compatibility, and failure rate measurement before a production rollout.
Most PQC TLS performance discussions repeat the same qualitative claim, “hybrid key exchange adds overhead”, without a repeatable way to measure what that overhead actually is in a specific environment. Published vendor numbers are a useful starting point, but they were measured on someone else’s infrastructure, network conditions, and traffic pattern. This guide is a lab plan for measuring it on yours.
Key Takeaways
- AWS’s published data shows hybrid ML-KEM key exchange adding roughly 1,600 bytes to the handshake and 80 to 150 microseconds of extra computation versus classical ECDH alone.
- Independent benchmarks using h2load found connection-establishment time increasing by roughly 23 percent when moving from X25519 to ML-KEM-512 hybrid key exchange under concurrent load.
- The overhead is incurred once per TLS session and amortized across its lifetime; high-frequency, short-lived connections feel it far more than persistent HTTP/2 or HTTP/3 connections.
- A complete lab plan measures seven distinct dimensions: handshake latency, CPU, memory, packet fragmentation, retransmission rate, proxy and middlebox compatibility, and outright failure rate.
- Testing only in a clean lab environment misses the failure modes that actually matter; realistic network conditions with packet loss and latency are where fragmentation and retransmission effects surface.
What Published Benchmarks Show
A handful of credible, published data points set expectations before you run your own tests. AWS has quantified the cost of moving from ECDH to an ECDH plus ML-KEM hybrid across its own TLS-terminating services: approximately 1,600 additional bytes transmitted during the handshake and an additional 80 to 150 microseconds of cryptographic computation for the ML-KEM operations. Independent academic benchmarking using h2load, measuring end-to-end request latency, TCP plus TLS handshake time, and time-to-first-byte under 100 concurrent clients, found mean connection-establishment time rising from roughly 24.7 milliseconds to 30.4 milliseconds when moving from classical X25519 to ML-KEM-512 hybrid key exchange, an increase of approximately 23 percent concentrated specifically in connection establishment rather than steady-state throughput.
These numbers are directionally useful but not a substitute for your own measurement. Different ML-KEM parameter sets, different hardware, different network paths, and different proxy or load balancer configurations all shift the actual numbers you will see.
See how HSM-as-a-Service supports ML-KEM key operations for TLS termination.
The Lab Plan: Seven Measurements
Build the test around a direct comparison: identical infrastructure, traffic pattern, and load, run once with classical-only key exchange and once with hybrid ML-KEM enabled.
1. Handshake Latency
Measure TCP-plus-TLS handshake time specifically, separated from total request latency, using a load-testing tool such as h2load or OpenSSL’s own s_time benchmarking utility. Run enough consecutive handshakes, 200 or more is a reasonable floor, to get a stable mean and standard deviation rather than a single noisy sample. Test at your production concurrency level, not a single-connection sanity check, since overhead behavior under concurrent load is what production traffic will actually experience.
2. CPU and Memory
Profile CPU time per handshake on both the client and server side, since ML-KEM key generation, encapsulation, and decapsulation each carry distinct computational cost. Track peak memory usage per connection as well; this matters disproportionately on constrained infrastructure or when running at very high connection concurrency where memory overhead per session compounds quickly.
3. Packet Fragmentation
Capture the actual ClientHello and ServerHello packet sizes with a tool like tcpdump or Wireshark, and confirm whether the hybrid handshake still fits within a single TCP segment on your network path’s MTU, or whether it now spans multiple segments. A hybrid ClientHello typically grows from roughly 300 to 500 bytes to approximately 1,300 to 1,500 bytes, still within a single segment on most networks, but confirm this against your actual MTU rather than assuming it.
4. Retransmission Rate
Test under realistic packet loss conditions, not just a clean lab network. Introduce controlled loss (a Linux tc netem configuration is a common way to do this) and measure whether the larger handshake payload increases the probability of a lost packet forcing a retransmission, which shows up as increased handshake latency under lossy conditions specifically, not under ideal ones.
5. Proxy and Middlebox Compatibility
Route test traffic through every TLS-terminating or TLS-inspecting component in your actual production path, load balancers, reverse proxies, next-generation firewalls, DLP appliances, not a direct client-to-server test alone. This is where the most common real-world failures occur: an appliance that does not recognize the hybrid group codepoint and rejects the connection outright rather than negotiating a classical fallback.
6. Failure Rate
Track the percentage of handshake attempts that fail outright, distinct from the percentage that succeed with degraded performance. A rising failure rate specifically correlated with hybrid negotiation, rather than a uniform baseline failure rate, is the clearest signal of a compatibility issue somewhere in the path rather than a simple performance cost.
7. Production-Representative Traffic Patterns
Run the full test suite against both a high-frequency, short-connection traffic pattern and a persistent, long-lived connection pattern. The overhead measured above applies once per connection, so a workload dominated by short-lived connections will show a proportionally larger performance impact than one dominated by long-lived, keep-alive connections, even though the per-handshake cost is identical in both cases.
What We’d Actually Recommend
Run all seven measurements before broad rollout, not just handshake latency in isolation; fragmentation and proxy compatibility are where production incidents actually originate, not raw CPU cost. Test against realistic network conditions, including packet loss, since a clean lab environment systematically understates the retransmission and latency effects that show up under real-world conditions. Prioritize testing high-frequency, short-lived connection workloads specifically, since that is where the per-handshake cost compounds into a measurable user-facing effect, and treat persistent-connection workloads as lower priority for performance testing, though still worth validating for compatibility.
How Encryption Consulting Can Help
The CPU and memory measurements in this lab plan depend on the ML-KEM implementation actually doing the key generation, encapsulation, and decapsulation work, and that is where HSM-as-a-Service fits: FIPS-validated, ML-KEM-ready key management that lets you benchmark hybrid handshake performance against production-grade hardware rather than a software-only approximation.
Our PQC Advisory Services build and run this kind of structured performance and compatibility test plan as part of a staged hybrid TLS rollout, translating the seven measurements above into a go or no-go decision for each traffic path in your environment before production exposure.
Measure Your Environment, Not the Vendor Slide
Published benchmarks from AWS and academic studies give a useful order of magnitude, roughly 1,600 bytes and under 150 microseconds per handshake in the best-documented case, but they were measured on infrastructure that is not yours. The lab plan in this guide, run against your own load balancers, proxies, and traffic patterns, is what actually tells you whether hybrid TLS is ready for your production environment, and where specifically it is not.
Frequently Asked Questions
How much extra latency does hybrid ML-KEM key exchange actually add?
Published figures range from roughly 80 to 150 microseconds of additional computation (AWS) to a measured 23 percent increase in connection-establishment time under concurrent load in academic benchmarking. The actual number depends heavily on your hardware, ML-KEM parameter set, and network conditions, which is why testing your own environment matters more than any single published figure.
Does hybrid TLS overhead affect every connection equally?
No. The overhead is incurred once per TLS handshake and amortized over the session’s lifetime, so persistent, long-lived connections feel it far less than high-frequency, short-lived ones where handshake cost is already a larger fraction of total connection cost.
What is the most common cause of hybrid TLS failures in production?
A proxy, load balancer, or inspection appliance in the traffic path that does not recognize the hybrid key exchange group and rejects the connection outright, rather than a raw performance problem. This is why testing through your actual production path, not just a direct client-to-server test, matters most.
Should performance testing happen in a clean lab environment or under realistic network conditions?
Both, but realistic conditions with introduced packet loss and latency are essential. A clean lab test will not surface the fragmentation and retransmission effects that matter most in real-world deployment, since those effects specifically depend on loss and latency conditions a clean lab does not have.
Does the hybrid ClientHello always fit in a single network packet?
For most standard network paths, yes; the hybrid ClientHello typically grows to roughly 1,300 to 1,500 bytes, still within a single TCP segment on most networks. Confirm this against your specific MTU rather than assuming it, particularly on networks with non-standard MTU configurations.
