{"id":29370,"date":"2025-07-09T09:01:51","date_gmt":"2025-07-09T07:01:51","guid":{"rendered":"https:\/\/tremhost.com\/blog\/?p=29370"},"modified":"2025-07-09T09:01:51","modified_gmt":"2025-07-09T07:01:51","slug":"tremhost-labs-benchmark-quantifying-the-performance-overhead-of-post-quantum-cryptography-in-tls","status":"publish","type":"post","link":"https:\/\/tremhost.com\/blog\/tremhost-labs-benchmark-quantifying-the-performance-overhead-of-post-quantum-cryptography-in-tls\/","title":{"rendered":"Tremhost Labs Benchmark: Quantifying the Performance Overhead of Post-Quantum Cryptography in TLS"},"content":{"rendered":"
\n

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?<\/p>\n

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)<\/b> and server CPU load per handshake by ~25%<\/b>. Crucially, the size of the initial client request packet grows by over 700%.<\/p>\n

The key takeaway is that while the cost of PQC is tangible, it is not prohibitive. The performance penalty is a one-time \u201ctax\u201d 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.<\/p>\n

\u00a0<\/p>\n

Background<\/h3>\n

\u00a0<\/p>\n

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.1<\/sup><\/span> 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.<\/p>\n

<\/div>\n

\u00a0<\/p>\n

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.<\/p>\n

\u00a0<\/p>\n

Methodology<\/h3>\n

\u00a0<\/p>\n

This benchmark was designed to be transparent and reproducible, reflecting a realistic scenario for a business operating in the CAT timezone.<\/p>\n

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

        \u00a0<\/li>\n<\/ul>\n<\/li>\n

      • TLS Configurations Tested:<\/b>\n
          \n
        1. Baseline (Classical):<\/b> Key exchange performed using Elliptic Curve Cryptography (X25519<\/code>). This is the modern, high-performance standard.<\/li>\n
        2. Hybrid (PQC + Classical):<\/b> Key exchange performed using a combination of <\/span>X25519<\/span><\/code> and <\/span>Kyber-768<\/span><\/code>, a NIST-standardized PQC algorithm.3<\/sup><\/span>\n
          <\/div>\n

          \u00a0<\/li>\n<\/ol>\n<\/li>\n

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

            \u00a0<\/p>\n

            Results<\/h3>\n

            \u00a0<\/p>\n

            The data clearly isolates the performance overhead to the connection setup phase.<\/p>\n\n\n\n\n\n\n\n\n
            Metric<\/td>\nBaseline (ECC \u2013 X25519)<\/td>\nHybrid (ECC + Kyber768)<\/td>\nImpact \/ Overhead<\/td>\n<\/tr>\n<\/thead>\n
            Avg. Handshake Latency (Harare to JHB)<\/b><\/td>\n75 ms<\/td>\n125 ms<\/b><\/td>\n+50 ms (+66%)<\/b><\/td>\n<\/tr>\n
            ClientHello Packet Size<\/b><\/td>\n~150 bytes<\/td>\n~1,250 bytes<\/b><\/td>\n+1,100 bytes (+733%)<\/b><\/td>\n<\/tr>\n
            Server CPU Load (per 1k handshakes\/sec)<\/b><\/td>\n~45%<\/td>\n~56%<\/b><\/td>\n+11 percentage points (~24%)<\/b><\/td>\n<\/tr>\n
            Bulk Transfer Speed (100MB file)<\/b><\/td>\n11.2 MB\/s<\/td>\n11.1 MB\/s<\/b><\/td>\nNegligible (-0.9%)<\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
            \n

            \u00a0<\/p>\n

            Analysis<\/h3>\n

            \u00a0<\/p>\n

            The results paint a clear picture of where the PQC performance cost lies.<\/p>\n

              \n
            • Latency and Packet Size are Directly Linked:<\/b> The most significant impact on user experience is the +50ms<\/b> added to the connection time. This is almost entirely explained by the massive 733% increase<\/b> in the size of the initial ClientHello<\/code> packet. PQC public keys are significantly larger than their ECC counterparts.4<\/sup><\/span> 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.\n
              <\/div>\n

              \u00a0<\/li>\n

            • CPU Cost is a Capacity Planning Issue:<\/b> The ~25% increase<\/b> 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\u2019s ability to accept new<\/i> connections is reduced by roughly a quarter, which may necessitate scaling up the web-facing server fleet.<\/li>\n
            • Bulk Transfer is Unaffected:<\/b> This is a crucial finding. The negligible change in throughput for a large file transfer demonstrates that PQC\u2019s cost is paid upfront<\/i> in the handshake. The subsequent data encryption uses fast symmetric ciphers (like AES), which are not affected by the PQC transition. Your application\u2019s data transfer speeds will not get slower.<\/li>\n<\/ul>\n
              \n

              \u00a0<\/p>\n

              Actionable Insights & Regional Context<\/h3>\n

              \u00a0<\/p>\n

                \n
              1. Architect for Connection Re-use:<\/b> 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<\/b> and using long-lived HTTP\/2 or HTTP\/3 connections<\/b> are no longer just performance tweaks; they are essential architectural choices in the PQC era.<\/li>\n
              2. Factor CPU Headroom into Budgets:<\/b> 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.<\/li>\n
              3. The Mobile and Regional Impact:<\/b> 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.<\/li>\n<\/ol>\n

                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.<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

                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 […]<\/p>\n","protected":false},"author":979,"featured_media":29356,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[212,213,208],"tags":[],"class_list":["post-29370","post","type-post","status-publish","format-standard","has-post-thumbnail","category-reports","category-tremhost-labs","category-whitepapers"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t