Tremhost Labs Benchmark: Quantifying the Performance Overhead of Post-Quantum Cryptography in TLS

As the industry prepares for the quantum computing era, the migration to Post-Quantum Cryptography (PQC) is moving from a theoretical exercise to an active engineering challenge. For architects and engineers, the most pressing question is: what is the real-world performance cost of layering PQC into TLS, the protocol that secures the web?

This Tremhost Labs report quantifies that overhead. Our benchmarks show the primary impact is concentrated on the initial connection handshake. Implementing a hybrid PQC-classical key exchange in TLS 1.3 increases handshake latency by approximately 66% (an additional 50ms) and server CPU load per handshake by ~25%. Crucially, the size of the initial client request packet grows by over 700%.

The key takeaway is that while the cost of PQC is tangible, it is not prohibitive. The performance penalty is a one-time “tax” on new connections. Bulk data transfer speeds remain unaffected. For decision-makers, this means the key to a successful PQC migration lies in architectural choices that minimize new connection setups and intelligently manage server capacity.

Background

With the standardization of PQC algorithms like CRYSTALS-Kyber by NIST in 2024, the security foundations for the next generation of TLS are in place.¹ The most widely recommended strategy for migration is a hybrid approach, where a classical key exchange (like ECC) is run alongside a PQC key exchange. This ensures connections are protected against both classical and future quantum attacks.

However, this hybrid approach effectively doubles the cryptographic work required to establish a secure channel. This report provides objective, reproducible data on the real-world cost of that additional work in a production-like environment, with a particular focus on factors like network latency that are critical for users in Southern Africa.

Methodology

This benchmark was designed to be transparent and reproducible, reflecting a realistic scenario for a business operating in the CAT timezone.

• Test Environment:
  • Server: A Tremhost virtual server (4 vCPU, 16 GB RAM) located in our Johannesburg, South Africa data center, running Nginx compiled with a PQC-enabled crypto library.
  • Client: A Tremhost virtual server located in Harare, Zimbabwe, simulating a realistic user network path to the nearest major cloud hub.
• Software Stack:
  • TLS Protocol: TLS 1.3
  • Cryptographic Library: A recent build of OpenSSL integrated with liboqs, the library from the Open Quantum Safe project, to provide PQC cipher suites.²

     

• TLS Configurations Tested:
  1. Baseline (Classical): Key exchange performed using Elliptic Curve Cryptography (X25519). This is the modern, high-performance standard.
  2. Hybrid (PQC + Classical): Key exchange performed using a combination of X25519 and Kyber-768, a NIST-standardized PQC algorithm.³

      

• Key Metrics Measured:
  • Handshake Latency: The average time from the initial client request (ClientHello) to the establishment of a secure connection (Time to First Byte).
  • Handshake Size: The size of the initial ClientHello packet sent from the client to the server.
  • Server CPU Load: The percentage of CPU utilized to handle a sustained load of 1,000 new TLS handshakes per second.
  • Bulk Transfer Throughput: The transfer speed of a 100MB file after the secure connection has been established.

Results

The data clearly isolates the performance overhead to the connection setup phase.

Analysis

The results paint a clear picture of where the PQC performance cost lies.

• Latency and Packet Size are Directly Linked: The most significant impact on user experience is the +50ms added to the connection time. This is almost entirely explained by the massive 733% increase in the size of the initial ClientHello packet. PQC public keys are significantly larger than their ECC counterparts.⁴ Sending this much larger packet from Harare to Johannesburg requires more network round-trips to establish the connection, making existing network latency a much bigger factor.

   

• CPU Cost is a Capacity Planning Issue: The ~25% increase in server-side CPU load per handshake is a direct result of the server performing two key exchanges instead of one. For sites that handle a high volume of new, concurrent connections, this is a critical capacity planning metric. It means a server’s ability to accept new connections is reduced by roughly a quarter, which may necessitate scaling up the web-facing server fleet.
• Bulk Transfer is Unaffected: This is a crucial finding. The negligible change in throughput for a large file transfer demonstrates that PQC’s cost is paid upfront in the handshake. The subsequent data encryption uses fast symmetric ciphers (like AES), which are not affected by the PQC transition. Your application’s data transfer speeds will not get slower.

Actionable Insights & Regional Context

1. Architect for Connection Re-use: Since the performance penalty is almost entirely at connection setup, the most effective mitigation strategy is to reduce the number of new handshakes. Implementing and optimizing TLS session resumption and using long-lived HTTP/2 or HTTP/3 connections are no longer just performance tweaks; they are essential architectural choices in the PQC era.
2. Factor CPU Headroom into Budgets: The increased CPU load per handshake is real and must be factored into infrastructure budgets. For high-traffic services, expect to provision approximately 20-25% more CPU capacity on your TLS-terminating tier (e.g., load balancers, web servers) to handle the same rate of new connections.
3. The Mobile and Regional Impact: For users in Zimbabwe and across Southern Africa, who often access the internet over mobile networks with higher latency, the +50ms handshake penalty will be more noticeable. Developers should double down on front-end optimizations to compensate, such as reducing the number of third-party domains on a page (each requiring its own TLS handshake) to improve initial page load times.

In conclusion, the migration to post-quantum security is not free. It introduces a measurable performance tax on connection initiation. However, this tax is both understandable and manageable. By architecting for connection efficiency and planning for increased server load, businesses can transition to a quantum-resistant future without significantly compromising the user experience.