Testing Ciphersuites For Performance
Since many of our DORA customers have already inquired about PQC testing, we have set up a test environment for our new generators to ensure that we can test TLS 1.3 and PQC on the same machine while measuring load, throughput, and response times.
We assumed that, particularly with modern load balancers that process “classic” TLS sessions in hardware (ASIC/FPGA) while PQC encryption algorithms are usually processed in software, a higher load should be measurable when using PQC encryption algorithms.
And we were right. In our client tests with hardware load balancers, we were able to overload the load balancers in 4 out of 5 cases by using valid PQC hybrid encryption suites.
In our tesbed with our own server, we tested pure TLS handshakes (HS) and GET requests for TLS 1.3 vs PQC hybrid ciphers (X25519MLKEM768), and pure PQC ciphers (MLKEM512).
We found that CPU utilization for hybrid and pure PQC encryption algorithms was more than twice as high as for TLS 1.3 handshakes (40% on average for TLS, 80% on average for PQC), indicating a significant increase in CPU utilization for PQC encryption algorithms, both for hybrid and pure PQC encryption algorithms.
We also observed in all tests that the performance of PQC ciphers was slightly better: about 10% for hybrid PQC ciphers and 20% for pure PQC ciphers, but this alone does not explain the 100% increase in CPU utilization.
Since modern hardware load balancers process their standard TLS sessions in hardware and PQC in software, the increase in CPU utilization on actual hardware will be significantly more dramatic
You should verify that you have selected the correct and high-performance encryption algorithms/methods and check whether your appliance/load balancer experiences performance issues with certain encryption suites, as we observed with a {redacted} hardware LoadBalancer, which was forced to constantly reboot as a result.
Checking PQC CipherSuites
We created a free Check-Service for admins who wants to check if their setups and services are PQC-ready: under https://test.full-spectrum-quantum.com/ you can run tests to see if your configuration works.
Please note: these tests are just configuration-checks, no load-tests; for the later one you might want to send an email to "pqc@zero.bs" or click the button
A perfect PQC-setup for different ciphers can be investigated by the Open Quantum Safe project who run a testserver under https://test.openquantumsafe.org/
When testing this server with our checktool, we get the following result:
Performance-Test-Setup
On the server-side we used a recent Ubuntu, vanilla-nginx, and openssl with TLS 1.3/PQC-enabled ciphers on a dedidcated 8 CPU server with 32 GB RAM (RAM wasnt the issue, but CPU was)
On the client/botnet-side we build a set of new traffic-generators that can perform basic TLS/PQC-Handshakes with selected ciphers, as well as full GET-reuqests, with 100 bots.
The goal was not to overload the server with requests, but rather to measure the load that a selected encryption suite places on the server, in order to compare the performance of TLS 1.3 with that of PQC encryption algorithms.
Load-measurements during the tests:
Why PQC Testing Should Be On Your Roadmap
With NIST finalizing core PQC standards in 2024 (including ML-KEM/FIPS 203, ML-DSA/FIPS 204, and SLH-DSA/FIPS 205) and selecting HQC as a backup in 2025, global adoption of post-quantum cryptography is accelerating rapidly in 2026. Governments and regulators - including the U.S. (via CISA and mandates), EU (national plans by end-2026, critical infrastructure by 2030), G7 financial sector roadmaps, Canada, and others - are driving mandatory migration timelines for critical systems. This creates cascading requirements across supply chains, cloud providers, CDNs, and enterprise networks, with hybrid PQC schemes (e.g., X25519MLKEM768) already appearing in TLS 1.3 implementations from major vendors, browsers, and load balancers.
Looking at the raw numbers, it is clear that global PQC-enabled HTTPS traffic stands at 70% (largely thanks to Google and Cloudflare), which means that the pressure on those who have so far ignored PQC will increase month by month
Testing PQC ciphers now is essential to assure operational readiness and quantify impacts on LoadBalancers (LBs) and ProxyServers, which serve as critical TLS termination points handling high volumes of handshakes. Unlike classical algorithms (RSA/ECC) that benefit from widespread hardware acceleration via ASICs, most PQC implementations (lattice-based like Kyber/ML-KEM or Dilithium/ML-DSA) currently rely on software execution on general-purpose CPUs. This introduces higher computational overhead for key encapsulation, signature generation/verification, and larger key/signature sizes, leading to increased CPU utilization, memory footprint, and handshake latency.
For more information, please see the article on our company website: "Navigating the Quantum Transition: Why 2026 is the Critical Year for PQC Adoption"
If you have any questions or need assistance with assessing, implementing, or testing PQC encryption algorithms, please click the button and contact us via our contact form; we have already integrated PQC-testcases into our Avydos platform:
Member discussion: