Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange

This paper presents a laboratory study analyzing the performance impact of traditional, hybrid, and pure post-quantum TLS 1.3 key exchange algorithms across multiple layers of stateful HTTP transactions, utilizing a load-balanced architecture to statistically evaluate latency and throughput variations under different response sizes.

The Gist

Here is an explanation of the paper, translated into everyday language with some creative analogies.

The Big Picture: Why Are We Doing This?

Imagine the internet is a giant, secure delivery service. Right now, the "locks" on the delivery trucks (encryption) are made of a special metal that is very hard to break. But scientists are worried that in the future, a new kind of "super-hammer" (a Quantum Computer) will be invented that can smash these locks open instantly.

To stop this, we need to build new, stronger locks (Post-Quantum Cryptography or PQC) that the super-hammer can't break. But before we replace all the locks on every truck in the world, we need to know: Will these new locks make the trucks drive slower?

This paper is a laboratory test to answer exactly that question. The researchers built a fake internet traffic system to see how much time these new "quantum-safe" locks add to a delivery.

---

The Experiment: A Five-Layer Race

To understand where the time is lost, the researchers didn't just look at the total time it took to get a webpage. Instead, they broke the process down into five distinct layers, like peeling an onion.

Think of sending a secure message like ordering a custom pizza:

1. The TCP Handshake (The Phone Call): You call the pizza place. They pick up. You say "Hello," they say "Hello." This is just setting up the line.
   • The Finding: The new locks didn't change this at all. The phone call took the same amount of time.
2. The "Pre-Game" (Client Initialization): Before you even order, you have to put on your apron and get your ingredients ready.
   • The Finding: This is where the new locks are heavy. Putting on the "quantum-safe" apron took about 6 times longer than the old one. This is because generating the new, complex keys takes more brainpower (CPU) on your computer.
3. The Order (TLS Handshake): You tell them what you want, and they confirm the order.
   • The Finding: Surprisingly, this part was almost the same speed for both old and new locks. Even though the new locks are mathematically more complex, the computer handled them so efficiently that the delay was invisible.
4. The Kitchen Wait (TLS-to-App): The time between confirming the order and the kitchen starting to cook.
   • The Finding: A tiny, barely noticeable delay, but nothing to worry about.
5. The Delivery (Application Response): The pizza actually driving to your house.
   • The Finding: This depends entirely on how big the pizza is (how much data you are downloading). The type of lock didn't matter here at all.

---

The Key Takeaways (The "So What?")

1. The "Heavy Lifting" Happens Before the Conversation

The biggest slowdown happens right at the start, when your computer is preparing the new keys (Layer 2). It's like the difference between a lightweight backpack and a heavy one; putting the heavy one on takes time, but once you are wearing it, walking the rest of the way isn't much slower.

2. The "Middle" is Surprisingly Fast

Many people thought the actual negotiation of the new locks (Layer 3) would be slow. The researchers found it wasn't. The new algorithms (ML-KEM) are so well-optimized that they run just as fast as the old ones during the handshake.

3. The "Big Pizza" Effect

If you are downloading a tiny text file (4 KB), the new locks add about 3 to 4 milliseconds to the total time. That's like adding a blink of an eye.
However, if you are downloading a huge video file (40 KB), that extra 3 milliseconds gets "diluted." It becomes a tiny percentage of the total time.

• Analogy: If you are walking 10 steps and you put on heavy boots, it takes you longer. But if you are walking 1,000 steps, the time it took to put on the boots barely matters in the grand scheme of the trip.

4. The "Client" vs. The "Server"

• Your Computer (The Client): Had to work about twice as hard to prepare the new locks. If you have an old phone or a small IoT device (like a smart thermostat), this might be a problem.
• The Website Server: Only worked about 5-6% harder. This is manageable for big servers, but if millions of people switch at once, servers might need to upgrade their hardware.

The Verdict

Good News: Switching to these "quantum-proof" locks is not going to break the internet. The slowdown is very small (less than 20% of the total time for small files, and even less for big files).

The Catch: The main cost is on the user's device (your phone or laptop) when it first connects. It has to do a bit more math to get ready.

Conclusion: We can start switching to these new locks now without worrying that our websites will become painfully slow. The "heavy lifting" is real, but it's a one-time cost at the start of the connection, and the rest of the journey is smooth sailing.

Technical Summary

Here is a detailed technical summary of the paper "Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange."

1. Problem Statement

The advent of cryptographically relevant quantum computers threatens current public-key infrastructures (PKI), necessitating a migration to Post-Quantum Cryptography (PQC). While NIST has finalized standards (FIPS 203/204/205) and organizations are preparing for "store now, decrypt later" attacks, there is a lack of empirical data quantifying the granular performance impact of PQC on TLS 1.3 transactions.

Previous studies often measured only aggregate handshake latency or focused on specific algorithms in isolation. This paper addresses the gap by decomposing the end-to-end transaction into specific protocol layers to determine exactly where and how much PQC overhead is introduced, distinguishing between classical, hybrid, and pure PQC configurations under realistic load conditions.

2. Methodology and Experimental Setup

The authors conducted a laboratory study using a controlled architecture to emulate a real-world production environment.

• Architecture:
  • Client: Keysight CyPerf (high-performance stateful traffic generator) emulating 100 Transactions Per Second (TPS).
  • Server: Nginx 1.27.3 acting as a TLS-terminating reverse proxy, compiled with OpenSSL 3.4.0 integrated with the Open Quantum Safe (OQS) provider.
  • Backend: A CyPerf agent returning HTTP responses.
  • Network: Three VMs connected via local networking to minimize external latency variables.
• Configurations Tested:
  • Classical: x25519 (ECDH).
  • Hybrid: x25519_MLKEM512 and x25519_MLKEM768 (combining ECDH with ML-KEM).
  • Pure PQC: MLKEM512 and MLKEM1024 (ML-KEM only).
  • Variables: Backend response sizes (Direct/Minimal, 4 KB, and 40 KB).
• Data Collection & Analysis:
  • Full packet captures (pcap) were recorded alongside SSLKEYLOGFILE to enable decryption.
  • A custom Python tool (pcap_layer_analysis) decrypted streams and extracted timestamps at five specific protocol boundaries.
  • Statistical Metrics: Mean, median (p50), percentiles (p90, p95, p99), and standard deviation were calculated.
  • Effect Size: Glass's $\Delta$ was used to determine if latency differences were practically meaningful (Cohen's thresholds: <0.2 negligible, 0.2–0.8 small/medium, >0.8 large).

3. Key Contributions

1. Five-Layer Decomposition: The study introduces a methodology to break down TLS 1.3 latency into five distinct phases:
   1. TCP Handshake (SYN $\to$ SYN-ACK)
   2. TCP-to-TLS Delay (SYN-ACK $\to$ ClientHello)
   3. TLS Handshake (ClientHello $\to$ Finished)
   4. TLS-to-Application Delay (Finished $\to$ HTTP GET)
   5. Application Response (HTTP GET $\to$ 200 OK)
2. Algorithm-Neutral Handshake Finding: The paper demonstrates that the TLS Handshake layer itself is effectively algorithm-neutral, showing negligible performance differences between classical, hybrid, and pure PQC.
3. Identification of the Bottleneck: It isolates the TCP-to-TLS delay (client-side initialization) as the primary source of PQC overhead, rather than the cryptographic exchange itself.
4. Public Resources: The authors released a data-reduction tool and a dataset of decrypted packet captures to enable reproducible research.

4. Key Results

A. Latency Breakdown by Layer

• TCP Handshake: Unaffected by the cryptographic algorithm. Median latency remained stable (~0.36–0.40 ms) across all configurations.
• TCP-to-TLS Delay (The Dominant Cost): This layer showed the most significant impact.
  • Classical (x25519): ~0.29 ms.
  • PQC/Hybrid: ~1.7–1.9 ms.
  • Result: A 6x increase in latency ($\Delta \approx 7.7$). This is attributed to client-side key material generation and ClientHello construction.
• TLS Handshake: Surprisingly, this layer showed no practically meaningful difference.
  • Median latencies ranged from 5.25 ms (Pure PQC) to 6.50 ms (Hybrid).
  • Glass's $\Delta$ was between 0.03 and 0.33 (negligible to small).
  • Pure ML-KEM was not measurably faster or slower than classical ECDH at the protocol level, as protocol framing and network jitter absorbed micro-benchmark differences.
• Application Layer: Dominated by network path and payload size. PQC had no measurable impact here.

B. Normalized Overhead Metrics

• Overhead Factor (OF): The TCP-to-TLS layer had an OF of ~6.0x. The TLS Handshake OF was ~1.0x (neutral).
• Cryptographic Overhead Share (COS): Despite the 6x spike in one layer, PQC overhead accounted for only 6% to 14% of the total end-to-end connection time.
  • Hybrid configurations had the highest COS (10.6–14.1%).
  • Pure PQC configurations had the lowest COS (6.0–7.9%).

C. Impact of Payload Size

• Increasing the response body from 4 KB to 40 KB increased total latency but did not affect cryptographic layers.
• The relative PQC overhead decreased (dilution effect) from ~15% (4 KB) to ~8% (40 KB) because the application-layer transfer time grew while the fixed cryptographic cost remained constant.

D. Resource Utilization

• Client CPU: Approximately doubled under PQC configurations (from ~3.7% to ~8.2–8.7%), indicating a significant burden on client-side resources (critical for IoT/mobile).
• Server CPU: Showed a modest relative increase (5.8% for hybrids), but absolute usage remained low (15%).
• Network Traffic: Increased linearly with key size (from 32 bytes for x25519 to 1568 bytes for MLKEM1024), but this did not proportionally impact latency.

5. Significance and Conclusion

This study provides critical insights for network architects and security engineers planning PQC migration:

1. Migration is Feasible: The performance penalty of PQC is moderate (adding ~3–4 ms to total transaction time) and concentrated almost entirely in the client-side initialization phase.
2. Hybrid vs. Pure: Pure PQC (ML-KEM) is not significantly slower than Hybrid; in fact, it often yields a slightly lower Cryptographic Overhead Share (COS) because it avoids the double-computation cost of Hybrid.
3. Client-Side Bottleneck: The primary concern for PQC adoption is client-side CPU and latency, particularly for resource-constrained devices (IoT, mobile), rather than server-side throughput.
4. Network Devices: The authors highlight that Man-in-the-Middle (MiTM) devices (e.g., firewalls, load balancers) performing decryption/re-encryption will face the highest impact, as they must process both client and server-side PQC overhead simultaneously.
5. Future Work: The authors recommend stress testing at higher loads (>100 TPS) and evaluating PQC in real-world environments with commercial load balancers and inspection devices.

In summary, while PQC introduces a measurable latency cost during connection establishment, it does not degrade the steady-state performance of TLS 1.3, and the overall impact on end-to-end transaction time is manageable for most applications.