To benchmark post-quantum TLS, compare a classical key exchange (such as X25519) with a hybrid one (such as X25519 combined with ML-KEM-768) on the same server, client and network, and measure handshake time, handshake size, server CPU per handshake and throughput after the connection is set up. The extra cost of post-quantum key exchange sits almost entirely in the handshake, because the keys and ciphertexts are larger; bulk data is still encrypted with the same symmetric ciphers. This guide explains what changes, what to measure and how to run a fair test on your own infrastructure.
What changes when TLS goes post-quantum
In August 2024, NIST published FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). NIST describes it as the primary standard for general encryption, and it is based on the algorithm previously called CRYSTALS-Kyber. FIPS 203 defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in increasing order of security strength.
In TLS 1.3, the most common deployment is a hybrid key exchange: the client and server combine a classical elliptic-curve exchange with ML-KEM, so the connection stays secure as long as either one holds. The practical differences are:
- Bigger messages: an X25519 public key is 32 bytes. Under FIPS 203, an ML-KEM-768 encapsulation key is 1,184 bytes and its ciphertext 1,088 bytes. The client’s first message (ClientHello) and the server’s reply grow by roughly a kilobyte each.
- Extra computation: both sides do the classical and the post-quantum operations.
- Unchanged bulk encryption: once the handshake completes, data is protected with symmetric ciphers such as AES-GCM or ChaCha20-Poly1305, exactly as before.
Certificates and signatures are a separate migration. Most current deployments change the key exchange first and keep classical certificates.
Define the question first
Decide what you need to know before you measure anything. Typical questions are:
- How much longer does a new connection take for our users on their real network paths?
- How many more servers or cores do we need at peak connection rates?
- Do any clients, proxies or firewalls on our paths fail with the larger handshake?
Each question needs a different test. Latency questions need realistic network paths; capacity questions need load tests close to the server.
Set up a fair test environment
- One variable at a time. Use the same server, client, software build, certificate and network path for both configurations. Change only the key-exchange group.
- Record versions. Note the operating system, TLS library and version, web server and version, and CPU model. Results are not comparable across builds.
- Choose a capable library. OpenSSL 3.5 and later include ML-KEM; older versions need the Open Quantum Safe provider. Confirm which groups your build offers before testing.
- Use realistic paths. For latency, run clients from where your users are, for example from an office network in Harare to a server in Johannesburg. A test on the same machine hides network effects.
- Isolate the server. Run load tests on a server with dedicated CPU cores and nothing else running, so neighbouring workloads do not distort CPU figures.
What to measure
Handshake latency
Measure the time from starting the connection to completing the TLS handshake, separately from time to first byte, which also includes application work. With curl, the time_appconnect value reports when the TLS handshake finished. Take many samples, alternate between configurations, and report the median and 95th percentile rather than a single average.
Handshake size
Capture packets with tcpdump or Wireshark and record the size of the ClientHello and the server’s first flight. Note whether the ClientHello now spans more than one TCP segment, since this is where some middleboxes misbehave.
Server CPU per handshake
Generate a steady rate of new connections with a load tool such as h2load, with connection reuse disabled, and record CPU use at fixed connection rates. Then find the rate at which each configuration saturates the CPU.
Throughput after the handshake
Download a large file over an established connection in both configurations. You should expect no meaningful difference; if you see one, look for another variable that changed.
Failure rate
Count handshake failures and fallbacks to classical key exchange, especially from older clients and corporate networks.
Interpreting the results
- Latency is a per-connection cost. If your users make one connection and reuse it, the impact on page load is small. If your architecture opens many short connections, it adds up.
- Reduce new handshakes. HTTP/2 and HTTP/3 connection reuse, keep-alive and TLS session resumption all reduce how often a full handshake happens.
- Plan capacity at peak connection rate, not average traffic.
- Edge termination helps. If a CDN or reverse proxy terminates TLS close to users, the larger handshake travels a shorter distance.
Reporting results honestly
Publish your environment, versions, sample sizes, percentiles and raw data, and state the limits of the test. A result from one path, one server size and one library build is evidence about that setup, not a universal figure.
Frequently asked questions
Does post-quantum TLS slow down my whole website?
The extra work is in the handshake. Data transfer after the handshake uses the same symmetric encryption as before.
Do I need new SSL certificates for hybrid key exchange?
No. Hybrid key exchange works with existing certificates. Post-quantum signatures in certificates are a separate, later step. Tremhost supplies SSL certificates from DigiCert, Sectigo and others if you need paid certificates today.
Where can I run a test server near Southern African users?
A VPS in Johannesburg is usually the nearest major location for users in Zimbabwe and South Africa.
Next step
Tremhost KVM VPS plans start at $15 a month with dedicated cores, NVMe storage and full root access, in Johannesburg, New York, Miami, Limburg or Roubaix, which makes them suitable for controlled TLS tests.
