DEV Community: asif naeem

72% of the Top 1,000 Sites Already Speak Post-Quantum TLS. None of Them Can Prove Who They Are With It.

asif naeem — Sat, 07 Nov 2026 18:20:11 +0000

TL;DR

I probed the Tranco top 1,000 domains for post-quantum key exchange. 504 of the 695 that completed a TLS 1.3 handshake (72.5%) accept X25519MLKEM768. That's 50.4% of the full list.
Zero of 695 present a post-quantum certificate. Every leaf is RSA or ECDSA.
Key exchange has migrated; authentication hasn't started. This is the same gap Phase 4 hit from the server side, now visible from the client side across the public web.

Why this post isn't the one I promised

Part 5 ended with "Part 6: the SLH-DSA measurements, whenever the ecosystem catches up." The monitor is still reporting "not yet," so that post is still waiting.

The question I kept getting in the meantime was simpler: where is everyone else? Every migration-planning conversation starts there. So I pointed PQC-Probe, the scanner from Project 1 of this trilogy, at the top 1,000 sites on the public web.

The headline numbers

	Domains	Share
Completed a TLS 1.3 handshake	695	69.5% of 1,000
Accept X25519MLKEM768	504	72.5% of reachable · 50.4% of 1,000
Classical-only TLS 1.3	191	27.5% of reachable
Present a PQ (ML-DSA / SLH-DSA) certificate	0	0%

Two numbers, two different stories. Hybrid ML-KEM is already on most of the reachable web, largely because the big edge operators turned it on: google.com, cloudflare.com, facebook.com, apple.com and amazonaws.com all accept it, and a huge share of the top 1,000 sits behind one of them. Certificates are a different supply chain: a CA has to issue them, browsers have to trust them, and per Phase 4, server TLS stacks have to be able to serve them. None of that has happened yet for the public web.

Five things in the data I didn't expect

1. The very top lags behind. Ranks 1–100: 66.2% (45 of 68 reachable). Ranks 101–500: 72.7%. Ranks 501–1,000: 73.6%. Being bigger doesn't make a site earlier. The classical-only names in the top 100 include github.com, wikipedia.org, netflix.com, amazon.com, azure.com and yahoo.com. These are large organisations running their own TLS termination, and they move on their own schedule rather than inheriting a CDN default.

2. Microsoft is split down the middle. microsoft.com accepts X25519MLKEM768. office.com, live.com, bing.com, outlook.com and sharepoint.com don't. Most of that second group also rejects plain X25519 and only offers the NIST curves (P-256/P-384/P-521). Across the list, 31 sites refuse plain X25519, and they cluster around Azure Front Door (azurefd.net, azureedge.net) and US government domains (nist.gov, epa.gov, ca.gov), which is consistent with stacks configured for NIST-curve-only compliance. Twelve of those 31 still accept X25519MLKEM768. So "no X25519" and "PQ hybrid" aren't mutually exclusive, which is a fun one for anyone writing compliance policy.

3. There's exactly one PQ group that matters. Every site that accepts any ML-KEM hybrid accepts X25519MLKEM768. Not one site supports another ML-KEM group without it. SecP256r1MLKEM768 shows up on 102 sites (14.7%) and SecP384r1MLKEM1024 on 8 (1.2%), always alongside X25519MLKEM768. If you're picking one group to support client-side, the web has already picked for you.

4. 54 sites in the top 1,000 don't speak TLS 1.3 at all. Among them: baidu.com, mail.ru, mit.edu, linktr.ee and bsky.app. I re-checked the last three by hand, and each negotiated TLS 1.2 with no version forced. Post-quantum key exchange in TLS requires 1.3, so these sites are a full protocol upgrade away from even starting.

5. The failures are mostly not websites. Tranco ranks domains by DNS popularity, so the top 1,000 is full of infrastructure: akamai.net, gtld-servers.net, cloudfront.net, apple-dns.net. Of the 305 domains with no handshake, 197 have no IPv4 address at the bare domain, 39 have port 443 closed, 54 are TLS 1.2 or older, and 15 had TLS errors or were unstable under the probe. Any survey that reports "X% of the top 1,000" without saying what the denominator is will be off by about a third.

The scanner bugs were the most useful part of the method

This scan was a reminder of the series' recurring lesson: the measuring instrument hits its limits before the system under test does.

IPv6 that half-works. My first pilot had 4 of 5 top domains "failing" at exactly the 5-second timeout. The handshake was fine. My ISP hands out IPv6 addresses but doesn't route them, so openssl s_client tried the AAAA record first and stalled about 5 seconds before falling back to IPv4. With -4 the same handshake took 0.11 s. The scan is IPv4-only as a result.

A tool that won't hang up. After a successful TLS 1.3 handshake, s_client can wait seconds for the server to close the connection. The probe waited for the process to exit, so short timeouts threw away handshakes that had already succeeded. The fix was to stream the output and kill the process the moment the handshake summary is printed. A side effect: timed-out probes no longer leave orphaned openssl processes behind.

Self-inflicted load. Pass 1 ran 50 domains in parallel, each trying 7 key-exchange groups. That's up to 350 concurrent openssl processes on a laptop on home Wi-Fi. Median probe time rose from about 130 ms in the pilot to 843 ms, and 183 domains timed out, including amazon.com and linkedin.com. Worse, it produced a believable false result: youtube.com showed up as "X25519MLKEM768 only, no plain X25519." Re-probed alone, it accepts X25519, P-256 and X25519MLKEM768 like the rest of Google.

The fix was a retry pipeline. Failures and suspicious rows were re-probed at concurrency 10 with a 10 s timeout, then still-failing domains were tried as www.<domain>, and the last 12 suspect rows were probed one at a time. A retry could only replace an earlier row if it succeeded, and it could never downgrade a PQ result. Every row in the published CSV records which pass produced it. Without this step the headline would have read 70.2% over 551 reachable sites instead of 72.5% over 695. That's a small difference in the percentage but a large one in coverage, and coverage determines whether the number means anything.

Method

Target list: Tranco list K9YYW, top 1,000, downloaded and scanned 6 November 2026.
Probe: PQC-Probe scan subcommand, commit 274f475, shelling out to OpenSSL 3.5.2 (s_client -4 -tls1_3 -groups <group>). Each domain was offered each of seven groups on its own: X25519, P-256, P-384, P-521, X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024.
Vantage point: a single home ISP connection in Dhaka, IPv4 only.
Passes: pass 1 (concurrency 50, 5 s timeout) → retry (concurrency 10, 10 s) → www. fallback → targeted re-probe (concurrency 1, 15 s). Final rows by pass: 840 / 73 / 75 / 12.
Failure classification: IPv4 DNS lookup → TCP connect to :443 → handshake with no version forced.

What the numbers do and don't mean:

"Accepts X25519MLKEM768" means the handshake succeeds when that's the only group offered. It doesn't tell you what a browser ends up negotiating. That depends on client preference and on the server's group order.
"Certificate signature algorithm" is the CA's signature on the leaf certificate. The chain above it wasn't inspected. That's the next PQC-Probe feature.
Bare domains first, www. only as a fallback. One vantage point, one day. CDN edges can behave differently by region.

What to do with this

If you run a site behind a major CDN, you probably already accept hybrid PQ key exchange. Check it rather than assuming:

openssl s_client -connect yoursite.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i "negotiated"

(This needs OpenSSL 3.5+. If it errors with "unknown group," your client is too old to test.)

If you terminate TLS yourself, you're probably in the 27.5%. Phase 1 measured the cost of switching on X25519MLKEM768 at 0.3 ms per handshake, and Phase 3 found no measurable difference at WAN latency. The cost is a config line and an OpenSSL upgrade.

If you're planning certificate migration, this data confirms the ecosystem hasn't moved. That's not a reason to wait. Inventory now, so you know which of your certificates, chains and TLS terminators will need to change when CAs start issuing ML-DSA. That inventory is Project 2 of this trilogy.

Data

Raw CSV (1,000 rows, one per domain, with the pass that produced each row and a failure classification), the scanner, the retry pipeline and the analysis script are all in pqc-probe under results/. If you scan from a different vantage point or a later Tranco list, I'd like to compare.

Next in the series: whichever comes first, the SLH-DSA measurements when the monitor turns green, or the operational cost of running nginx with PQ TLS under live load.

Retro : What I Measured, What I Can't, and What You Can Deploy Today

asif naeem — Fri, 23 Oct 2026 17:57:12 +0000

TL;DR

ML-DSA-65 at TLS 1.3 is production-ready today. Hybrid KEM (X25519MLKEM768) too. Both have no measurable penalty over classical at WAN RTT.
SLH-DSA cannot be served over TLS yet with any public stack I tested. The crypto and X.509 layers work; the TLS integration layer isn't shipping.
When ecosystem support has layers, "shipping" the algorithm doesn't mean "shipping" the deployment.

What I set out to do

Six weeks ago I started pqc-bench to answer a specific question: how much does post-quantum TLS 1.3 cost me, in milliseconds, at scales and distances that match a real deployment? The project was going to be five phases of measurement ending with a cert-size × WAN RTT scenario built around SLH-DSA's 17 kB signature forcing an extra round-trip through TCP's initial congestion window.

The last phase didn't produce measurements. It produced a different kind of finding. This post ties it to the four that worked.

The four phases that worked

Phase 1 — fresh handshake latency, same-AZ. X25519MLKEM768 vs X25519. Delta: 0.3 ms per handshake. Below the noise floor of ±1 ms RTT variance on a c7g.large same-AZ. The hybrid KEM extension is cheap.

Phase 2 — session resumption plus payload sweep (100 B / 10 kB / 100 kB). Classical and PQ statistically identical at every percentile post-resumption. The 1 MB arm had to be dropped — not because of crypto, because the instance's NIC saturated at 200 req/s × 1 MB ≈ 1.6 Gbps. I noted it for Phase 3's methodology and moved on.

Phase 3 — cert chain size × WAN RTT across three regions. ECDSA, RSA-2048, ML-DSA-65 × us-east-1, us-west-2, ap-northeast-1. Headline: cert-chain-size differences are statistically invisible at WAN RTT because TCP's initial congestion window (14.6 kB) absorbs the whole ML-DSA-65 chain in one round-trip. The only measurable delta — 1.5 ms — appeared at same-AZ ~1 ms RTT, where every tenth of a millisecond is visible. I also reran the 1 MB payload at 20 req/s and confirmed Phase 2's 1 MB failure was 100% NIC saturation, no crypto effect.

Phase 4 Part 1 — SLH-DSA at WAN RTT. Planned as the clean counterexample: 17 kB signature → ~20 kB cert chain → one extra round-trip. Tested the premise; the ecosystem couldn't run the experiment.

The three layers

Phase 4's finding fits in one picture.

TLS support for a signature algorithm has three layers, and all three have to arrive together before a deployment is possible:

Cryptographic primitives. openssl genpkey, sign, verify.
X.509 encoding. OIDs recognised when parsing cert ASN.1.
TLS protocol integration. SSL_CTX_use_certificate accepts the cert, ClientHello's signature_algorithms extension advertises the type, CertificateVerify is signed with it.

OpenSSL 3.5.2 has all three for ML-DSA. For SLH-DSA, it has layers 1 and 2 only. oqs-provider 0.12.0-dev doesn't fill the TLS gap — it deferred SLH-DSA to OpenSSL's default provider now that 3.5.2 has native support, and the default provider doesn't reach layer 3. The hand-off left a hole nobody owns right now.

What you can deploy today

You want to…	Status
Serve ML-DSA-65 cert over TLS 1.3	✓ Production-ready, OpenSSL 3.5.0+
Serve SLH-DSA cert over TLS 1.3	✗ Not with any public stack I tested
Sign JWT / firmware / packages with SLH-DSA	✓ OpenSSL 3.5.2 keygen + sign work
Use hybrid KEM (X25519MLKEM768) in TLS 1.3	✓ OpenSSL 3.5.0+, both ends
Store an SLH-DSA cert in a certificate store	✓ X.509 layer accepts it
Negotiate PQ cert selection via SNI	✓ If the cert is ML-DSA

What the series taught me

Three things I'll carry into the next two projects.

"Measurable" is a hypothesis. Phase 1 and Phase 3 both predicted measurable PQ overhead at the chosen scale, and both got noise. That's a less-sexy finding, but it's the useful one for the people who have to decide whether to deploy: ML-DSA is cheap enough that the decision is "yes, when you're ready," not "yes, if you can afford the latency."

Infrastructure limits dominate crypto costs more often than crypto costs dominate anything. Phase 2's 1 MB payload failure wasn't about PQ. It was about a $0.14/hr instance pegging its NIC at 1.6 Gbps. The methodology note that caught it was more informative than any signature-algorithm observation in the whole series. Pick instance sizes that make the crypto, not the network, the bottleneck — otherwise you're measuring the wrong thing.

"Supported" has layers. Phase 4's lesson is the one I'll keep closest. OIDs, TLS codepoints, keygen implementations, and TLS handshake integrations are four different things that have to ship together before a deployment is possible. "SLH-DSA is in OpenSSL 3.5" is correct at the first two layers and misleading at the third.

What's next

A GitHub Actions cron builds the latest OpenSSL 3.5.x and oqs-provider main on the 1st of each month and checks openssl list -tls-signature-algorithms for SLH-DSA entries. Running log at the tracking issue. The day it reports "yes," Phase 6 of pqc-bench measures what Phase 4 was supposed to.

The series' underlying lesson — that "support" has layers that can arrive separately — becomes the core of Project 1 of the trilogy: PQC-Probe, a scanner that reports what a given host supports across SSH and TLS, in both vanilla and experimental PQ stacks. When those answers differ, that gap is actionable.

Thanks for following along, five posts in. The repo is at pqc-bench and pqc-bench-slh-dsa. The data, the terraform, the user-data scripts, and the full logs of every failure mode are all there. Fork what's useful.

Follow for Part 6 — the SLH-DSA measurements, whenever the ecosystem catches up.

PQC-Bench Part 4: SLH-DSA over TLS failed

asif naeem — Sun, 18 Oct 2026 14:05:36 +0000

TL;DR

SLH-DSA signatures are ~17 kB. That’s bigger than TCP’s initial congestion window (14.6 kB), so a cert chain with SLH-DSA would need an extra round-trip to deliver. I wanted to measure that effect at WAN RTT.
We can generate SLH-DSA keys and sign things with them in OpenSSL 3.5.2. We cannot serve an SLH-DSA cert over TLS 1.3 — not with vanilla OpenSSL, and not with oqs-provider 0.12.0 either.
The TLS layer is a gap. SLH-DSA is production-ready for our signing API. It is not production-ready for our TLS terminator. Here’s exactly where the gap lives.

Context

In Phase 3 of pqc-bench (Part 3 here) we measured the handshake latency of ML-DSA-65, ECDSA, and RSA-2048 across three AWS regions. Recap: cert-chain-size differences are statistically invisible at WAN RTT when the whole chain fits inside TCP’s initial congestion window of 14.6 kB. ML-DSA-65’s 3.3 kB signature → 5–6 kB chain → fits comfortably in one round-trip. No measurable penalty.

Phase 4 was going to extend that: pick the one PQ signature algorithm whose chain doesn’t fit, measure the extra round-trip explicitly, and close the story. SLH-DSA-SHA2-128f was the obvious choice. Its 17,088-byte signature puts the chain around 20 kB — the first PQ signature at NIST level 1 that would force a second RTT.

What was supposed to be an evening of config bumping turned into three distinct failures that each taught me something about how PQ TLS support actually ships in the real world.

Attempt 1:

OpenSSL 3.5.0 lists SLH-DSA but can’t generate keys

My Phase 1–3 AMIs were built on OpenSSL 3.5.0, released May 2026. The algorithm registry looked promising:

$ /opt/openssl-3.5/bin/openssl list -public-key-algorithms | grep SLH Name: OpenSSL SLH-DSA-SHA2-128f implementation IDs: { 2.16.840.1.101.3.4.3.21, id-slh-dsa-sha2-128f, SLH-DSA-SHA2-128f }
But:

$ openssl genpkey -algorithm SLH-DSA-SHA2-128f -out slh.key Error: unsupported algorithm

OIDs registered, operations not implemented. OpenSSL 3.5.2 (Aug 2026) fills this in.

Next attempt: Rebuild the AMI, bump the pin. ~20 minutes.

Attempt 2:

3.5.2 keygen works, nginx still can’t serve the cert

With 3.5.2 baked, keygen succeeds:

$ openssl genpkey -algorithm SLH-DSA-SHA2-128f -out /tmp/t.key && echo OK OK $ openssl req -new -x509 -key /tmp/t.key -out /tmp/t.crt -days 365 -subj "/CN=test" $ wc -c /tmp/t.crt 23556 /tmp/t.crt

~23 kB cert chain — exactly as predicted, well past initcwnd. The crypto all works. Hand this cert to nginx:

nginx
ssl_certificate /tmp/t.crt; ssl_certificate_key /tmp/t.key; ssl_protocols TLSv1.3; ssl_conf_command SignatureAlgorithms SLH-DSA-SHA2-128f; $ sudo nginx-pq -t nginx: [emerg] SSL_CTX_use_certificate("/tmp/t.crt") failed (SSL: error:0A0000F7:SSL routines::unknown certificate type)

nginx can’t load an SLH-DSA cert at all. The error comes from OpenSSL’s TLS layer, not nginx. Let's dig into why:

$ openssl list -tls-signature-algorithms | tr ':' '\n' | grep -i slh (empty) $ openssl list -tls-signature-algorithms | tr ':' '\n' | grep -i dsa mldsa44 mldsa65 mldsa87

OpenSSL 3.5.2 has SLH-DSA at the X.509 and signing layers, but not at the TLS layer. ML-DSA shows up as a TLS 1.3 signature algorithm. SLH-DSA doesn’t. The TLS code path has no idea what to do with an SLH-DSA cert.

The pattern recognition kicks in: this is what oqs-provider from the Open Quantum Safe project was built for. Install it alongside OpenSSL, get the missing TLS integration -> measure -> ship.
That was my next plan of action.

Attempt 3: oqs-provider doesn’t fix it either

Rebuilt from source: liboqs (shared), oqs-provider v0.12.0-dev linked against OpenSSL 3.5.2, both installed into /opt/openssl-3.5.2/. openssl.cnf activates it at init:

`[provider_sect]
default = default_sect
oqsprovider = oqsprovider_sect

[default_sect]
activate = 1

[oqsprovider_sect]
activate = 1`

Smoke test:

$ openssl list -providers Providers: default name: OpenSSL Default Provider version: 3.5.2 status: active oqsprovider name: OpenSSL OQS Provider version: 0.12.0-dev status: active

Both active. Good start. Then:

$ openssl list -signature-algorithms | grep -i slh { 2.16.840.1.101.3.4.3.21, SLH-DSA-SHA2-128f } @ default (... all other SLH-DSA variants, all @ default ...)

Every SLH-DSA entry shows @ default. Zero @ oqsprovider. Which means oqs-provider v0.12 has stopped claiming SLH-DSA — it defers to OpenSSL’s default provider now that 3.5.2 has native SLH-DSA keygen and signing.

OK, the registration moved. Does the TLS layer work now? Let's try to serve the cert:

$ openssl s_server -key /tmp/t.key -cert /tmp/t.crt -accept 127.0.0.1:8443 -tls1_3 Using default temp DH parameters error setting certificate error:0A0000F7:SSL routines:ssl_set_cert:unknown certificate type:ssl/ssl_rsa.c:269

Identical error to attempt 1. oqs-provider ceded SLH-DSA to the default provider, but OpenSSL’s default provider still has only two of the three layers it needs. Nobody is wiring up SLH-DSA at the TLS layer in October 2026.

The three layers

TLS support for a signature algorithm isn’t one thing. It’s three layers that have to arrive together:

Cryptographic primitives — keygen, sign, verify. openssl genpkey -algorithm X works.
X.509 encoding — the algorithm’s OID is understood when parsing cert ASN.1. openssl req -new -x509 -key X works.
TLS protocol integration — the algorithm is advertised in ClientHello’s signature_algorithms extension, accepted by SSL_CTX_use_certificate, selected during negotiation, carried in CertificateVerify.

For ML-DSA, all three are in OpenSSL 3.5.2’s default provider. You can genkey, you can sign a cert, nginx can serve it, clients negotiate it. Full stack.

For SLH-DSA, OpenSSL 3.5.2 has layers 1 and 2. Nobody has layer 3 yet. Not OpenSSL’s default. Not oqs-provider 0.12. The error isn’t an obscure config nit — it’s ssl_set_cert saying “I don’t know what this is.”

What this means if you’re planning PQ TLS

Use ML-DSA if your TLS stack is OpenSSL ≥ 3.5.0 or anything built on it (nginx, Envoy, HAProxy with modern crypto, Go ≥ 1.24). It works today, chain fits in initcwnd for the common security levels (ML-DSA-65 at NIST level 3), no RTT penalty vs classical.

Do not plan an SLH-DSA deployment at the TLS termination layer today. The ecosystem gap is real and precise: X.509 cert works, signing API works, TLS handshake fails. If you have a signing use case that fits (JWT, firmware, package signatures, code signing), SLH-DSA is production-ready for that right now — just not through your TLS listener.

Monitoring the gap close

The simplest check from any machine with OpenSSL 3.5.2 and oqs-provider installed:

bash
openssl list -tls-signature-algorithms | tr ':' '\n' | grep slh

The day this returns slhdsasha2128f (or similar), SLH-DSA at TLS has arrived, probably in a new oqs-provider release that re-registers the TLS codepoints after OpenSSL added the keygen. I’ll be checking monthly. When it changes, Phase 5 of pqc-bench measures what I set out to measure tonight.

What’s in the repo

pqc-bench-slh-dsa on GitHub has all the exercise frozen in a branch: the user-data templates that build the full oqs-provider stack, the acceptance tests that fail cleanly, and the full logs of all three failure modes. If you’re staring at a 0A0000F7 error from your own PQ experiment, you’ll find the exact same thing in those logs.

pqc-bench Part 3: ML-DSA-65 certs are 10 bigger than ECDSA — and don't cost a thing on real networks

asif naeem — Sun, 11 Oct 2026 11:39:49 +0000

Part 1 measured post-quantum TLS handshake cost at same-AZ latency and found about 1 ms added per handshake. Part 2 showed that session resumption makes that cost disappear entirely for ongoing connections. That left one PQ overhead lever unmeasured: cert chain size. ML-DSA-65 signatures are around 3.3 kB and the public key is another ~1.9 kB. Combined, the whole cert file is about 10× the size of an ECDSA P-256 cert. Common intuition says that would hurt the handshake at high RTT, because every extra TCP segment to deliver the cert costs an extra round-trip.

The data says the opposite. At realistic WAN RTT, cert size is statistically invisible.

Setup

Same c7g.large Graviton3 target in us-east-1 as Phase 1 and 2. New dimension: a single loadgen deployed in three different AWS regions per night, hitting the same target through its public IP. That gave three natural RTT points:

Loadgen region	Measured RTT to target	Role
us-east-1 (same-AZ)	~1 ms	baseline, matches Part 1/2 conditions
us-west-2 (Oregon)	~70 ms	typical North-America east↔west
ap-northeast-1 (Tokyo)	~148 ms	trans-Pacific

Target serves one of three cert types per run, picked by a cert_type terraform variable (ECDSA P-256 / RSA-2048 / ML-DSA-65). Each cert type is tested with 3 trials × 60 s per trial. 27 trials total.

Cert file sizes on disk (the input to this experiment):

Cert type	File size	Signature size	Public key
ECDSA P-256	741 B	~70 B	~65 B
RSA-2048	1,277 B	256 B	~270 B
ML-DSA-65	7,680 B	3,309 B	1,952 B

Ratio 1 : 1.7 : 10.4. ML-DSA-65 is unambiguously the big one. The question Phase 3 asks: does that size translate into measurable handshake time?

Methodology detour: Gatling can't parse ML-DSA certs

The first attempt used Gatling for consistency with Phase 1/2. It failed immediately on the ML-DSA arm: 100% handshake failures. JDK 21's X509 parser rejects the ML-DSA-65 public key OID (2.16.840.1.101.3.4.3.17) during certificate deserialization, which happens before any trust-all client config can take effect. Even with -Dgatling.http.ssl.trustAll=true, the handshake never gets past the Certificate message.

OpenSSL 3.5 handles all three sig algorithms natively, so Phase 3 switched the measurement tool from Gatling to openssl s_time. Trade-off: no per-handshake percentile data, just aggregate mean (count × wall time → average). For a cert-size experiment that's acceptable — the signal shows up as a mean delta, not a tail distribution. Switching tools mid-phase was ugly but is itself a real-world finding worth noting: the client-side tooling that will dominate real-world PQ TLS adoption is still catching up to the server side.

Results

Mean handshake time per trial, across all 27 trials:

Region	ecdsa	rsa-2048	ml-dsa-65	Max spread
us-east-1 (~1 ms)	1.67 ms	2.86 ms	3.16 ms	1.49 ms
us-west-2 (~70 ms)	209.9 ms	211.6 ms	211.3 ms	1.7 ms
ap-northeast-1 (~148 ms)	445.3 ms	444.2 ms	445.3 ms	1.1 ms

At same-AZ, there is a measurable delta: ML-DSA-65 adds about 1.5 ms over ECDSA (+89%). That matches intuition — the extra cert bytes and the extra signature parse/verify CPU time cost about 1.5 ms when everything is sub-millisecond.

At 70 ms RTT, the delta collapses to 0.7%. At 148 ms RTT, it is statistically zero — ECDSA and ML-DSA-65 numbers are identical to one decimal place.

Trial-to-trial standard deviation was <3 ms at every region, so these aren't noisy numbers hiding a signal. The signal just isn't there.

Why cert size doesn't matter at WAN RTT

TCP's initial congestion window (initcwnd) on modern Linux kernels is 10 segments ≈ 14.6 kB (10 × ~1460-byte MSS). That's the amount of data a server can send in the very first flight after the handshake completes without waiting for the client to ACK anything.

A full TLS 1.3 ServerHello carrying the entire ML-DSA-65 cert chain is around 7.7 kB. Smaller than initcwnd. Which means the server delivers the whole thing in a single flight, in a single round-trip, regardless of whether it's a 700 B ECDSA cert or a 7.7 kB ML-DSA cert. No extra round-trip to pay for.

What would break this: a cert bigger than initcwnd. SLH-DSA signatures are ~17 kB — comfortably past the limit. That's the one PQ sig algorithm where cert size should measurably hurt at WAN RTT. That’s on the Phase 4 agenda.

Closing the Phase 2 1M-payload note

Part 2 flagged that the 1 MB payload arm failed because of NIC (network interface card) saturation — 200 users/sec × 10 reqs × 1 MB ≈ 16 Gbps is well above the c7g.large’s sustained throughput. The measurement was bandwidth-bound, not crypto-bound. As promised, here’s the rerun at a low rate.

Rerun done at 20 users/sec × 10 reqs × 1 MB ≈ 1.6 Gbps (within instance burst envelope):

Arm	req_total	p95	p99	max	% success
classical-1M	60,000	2 ms	2.33 ms	5.33 ms	100%
pq-1M	60,000	2 ms	2.00 ms	5.33 ms	100%

Classical and PQ are statistically identical at every percentile, confirming the Phase 2 failure was 100% NIC saturation. Once the handshake completes, every byte of application data is encrypted with AES-256-GCM regardless of which KEM negotiated the key — so the KEM choice stops mattering the moment the handshake amortizes.

What this changes

Three places PQ TLS overhead could show up:

Handshake KEM: ~1 ms at same-AZ (Part 1), 0 ms when resumed (Part 2)
Cert chain size: 1.5 ms at same-AZ, 0 ms at any WAN RTT (Part 3)
Record layer: identical across KEMs regardless of payload size (Part 2 + 3)

Across all three levers in all three parts, the only consistently measurable PQ cost is Part 1's +1 ms fresh handshake at low RTT. Everywhere else, PQ hides inside the regular protocol overhead.

If you’re planning the migration to X25519MLKEM768 + ML-DSA-65 and bracing for a user-perceived latency hit at WAN RTT because of certificate size, the data suggests you can stop worrying about that specific lever.

A few honest caveats

This finding breaks if the cert gets bigger than ~15 kB. TCP ships the first ~15 kB of data in one round-trip; ML-DSA’s 7.7 kB fits comfortably. SLH-DSA signatures are around 17 kB — big enough to need a second round-trip, and that would show up at WAN RTT. Different signature, different story.
Signing takes CPU time too, not just bandwidth. ML-DSA signing on c7g.large is a few hundred microseconds — too small to notice next to a 70 ms round-trip. On smaller machines (think Raspberry Pi–class hardware or t4g.small), the CPU cost would be a bigger slice of the total and might become visible.
Three trials per arm is enough for a solid mean, but tight for tail behavior. For p99-level claims I’d want 10+ trials.
This measures the TLS handshake only. The rest of the PQ cert story — longer chains when an intermediate CA is also signed with ML-DSA, bigger OCSP/CRL fetches to check revocation — is a different experiment.

What's next

Phase 4 candidates:

SLH-DSA cert (~17 kB) at WAN RTT — the one PQ sig that should break the initcwnd boundary and finally show the cert-size effect people expect.
Cross-architecture: c7g (Graviton3) vs c7i (Sapphire Rapids) vs c6a (AMD). Does the ML-DSA signing-side CPU cost change the picture on x86?
Realistic client mix: 80% resumed + 20% fresh across varying RTT, weighted average.

Code and raw results on GitHub. To reproduce the cert-size scenario: see scenarios/04-cert-chain-size/ and docs/03-phase-3-walkthrough-night1.md. Cost for all 27 trials across 3 regions: about $0.75 on on-demand c7g.large.

Full series:

Part 1 — Fresh-handshake latency
Part 2 — Session resumption + payload sweep
Part 3 — this post

PQC-Bench Part 2: Where the X25519MLKEM768 overhead actually matters

asif naeem — Mon, 05 Oct 2026 08:22:41 +0000

Part 1 ran a fresh-handshake load test on a Graviton3 and measured what the ML-KEM half of X25519MLKEM768 adds to TLS 1.3 handshake latency. The headline was that hybrid PQ costs about an order of magnitude more at p95 under a stream of brand-new connections.

That's a correct number for a benchmark almost nobody runs in production.

Real HTTPS traffic doesn't handshake once per request. Browsers pool connections. Load balancers hold them open. TLS session tickets let returning clients skip the key exchange entirely. So the question Part 1 left open is: once we measure in a shape that looks like production, what does the PQ cost actually become?

What changed from Phase 1

Same infra, two toggles.

Server (terraform/target/user-data-fast.sh.tftpl):

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 1h;
ssl_session_tickets on;

Client (Gatling):

http.baseUrl(target)
    .shareConnections()      // ← the key change
    .disableCaching()
    ...

With shareConnections(), each virtual user does N requests over one TLS session instead of opening a new connection per request. That's how production clients behave.

Everything else is identical to Phase 1: c7g.large Graviton3 target running nginx-pq against the same c7g.large loadgen, OpenSSL 3.5, TLS 1.3, hybrid X25519MLKEM768 KEM, ML-DSA-65 server cert for PQ-capable clients and an ECDSA P-256 cert for BoringSSL-based ones. Full Phase 2 code is on GitHub.

Two scenarios on top of that.

Scenario 02 — session resumption

Four arms: classical-fresh, classical-resumed, pq-fresh, pq-resumed. 300 user-connections per second, 10 requests per user, 5-minute measurement, 3 trials per arm, 12 trials total.

The p95 for each arm, averaged across trials:

arm	p95 (ms)	p99 (ms)
classical-fresh	4	~11
classical-resumed	1	1
pq-fresh	5	~6
pq-resumed	1	1

p99 is noisy with 3 trials — the apparent PQ-faster-than-classical result at fresh p99 is within trial variance, not a real effect

Fresh PQ adds 1 ms at p95. That's smaller than Part 1's number, mostly because Phase 2 uses hybrid session-cache-enabled nginx-pq with a lighter config path for the sub-ms responses. The relative cost (+25% vs classical fresh) is still real.

Resumed PQ adds nothing. The resumed numbers for classical and PQ are byte-for-byte identical: 1 ms at p95, 1 ms at p99.

Scenario 02 — response time by percentile, PQ overhead fresh vs resumed

This makes sense once we remember what resumption does. A resumed TLS 1.3 session skips the key-exchange exchange entirely: the client proves it has the master secret via a PSK and the connection picks up where it left off. ML-KEM, X25519, ECDH — all irrelevant after the first handshake. From there every record is wrapped in AES-256-GCM, which doesn't care which KEM negotiated the keys that derived the GCM key.

The resumption gain itself (3-4 ms off the p95) is bigger than the PQ cost (1 ms added). Any production fleet already running session resumption gets PQ migration essentially for free at this percentile.

Scenario 03 — payload sweep

Six arms: classical and pq × response sizes 100B, 10K, 100K. All connections resumed (shareConnections on, 10 requests per user). 200 users per second, 5-minute measurement, 3 trials per arm.

arm	p95 (ms)	max (ms)
classical-100B	1	7.00
classical-10K	1	5.33
classical-100K	1	7.33
pq-100B	1	6.33
pq-10K	1	5.67
pq-100K	1	6.00

Identical at every percentile. Max response time wobbles 5.33 → 7.33 ms but the spread is network jitter, not a classical-vs-PQ signal.

Scenario 03 — p95 across payload sizes, PQ overhead flat at zero

Same reason as before. Once the handshake amortizes over 10 requests, what is left is pure record-layer throughput, and the record layer is identical for each group. The AES-GCM path through c7g.large is the same whether the master secret came from X25519 or X25519MLKEM768.

The 1M arm I wanted to add didn't produce usable data: 200 users/sec × 10 requests × 1 MB = ~16 Gbps steady aggregate throughput, and c7g.large has a 0.75 Gbps NIC baseline (12.5 Gbps burst, but nothing like 16 Gbps sustained). The target hit NIC saturation and the trials filled the 60s-timeout bucket. That measurement was bandwidth-bound, not crypto-bound. 1M belongs in its own low-rate scenario - targeting for next phase.

What this changes

Three places PQ overhead can show up in a TLS deployment: handshake, cert chain, record layer. In Phase 2, we have measured two of them.

Handshake: 1 ms added at p95 for fresh connections. Zero for resumed.
Record layer: no measurable difference at any payload size up to 100 KB.

Which leaves cert-chain size — ML-DSA-65 signatures (size around ~3.3 kB ) vs ECDSA (~70 B) — as the remaining lever, and that one lands on cold or infrequently-resumed clients where the bigger ServerHello matters. That could be our next part (phase 3) area.

If we believe our production traffic looks more like scenario 02 and scenario 03 than like Phase 1 — and for most HTTPS services behind a connection pool, it does — then the practical cost of migrating to X25519MLKEM768 on current ARM server hardware is on the order of 1 ms at p95, paid once per client per session cache lifetime.

A few honest caveats

Gatling 3.15 reports response times in integer milliseconds, so sub-millisecond latencies round down to zero. The mean, p50, and p75 columns in both scenarios read as 0 ms for most arms — that is a measurement limitation, not real floor behavior. At p95 and above the numbers are above 1 ms and real, which is what the comparison relies on.

Three trials per arm is enough for the clean comparisons made here but tight for tail percentiles. The p99 column has noise comparable to the signal; I'd want 10 trials before saying anything confidently about p99 behavior.

NIC saturation at 1M payloads means Phase 2 is silent on how PQ scales under high-bandwidth sustained workloads. That is a different question to answer with different setup.

What's next

Phase 3 candidates, roughly ordered:

Cert-chain size impact: how much does the ~3 kB ML-DSA-65 signature cost at the first-byte percentile across varying RTT? ML-DSA-65 vs ECDSA, same target.
1M payload at a sane rate (~20 rps) — bandwidth characterization, not primarily crypto.
Realistic client mix: 80% resumed + 20% fresh, measuring aggregate p95 as a weighted average the way CDN telemetry would see it.

Code and raw results for Phase 2 are on GitHub. To reproduce: ./scenarios/02-resumption/run.sh 300 3 10 and ./scenarios/03-payload-sweep/run.sh 200 3 10. Total cost on on-demand c7g.large is about $0.50. Based on my experience it can and will interrupt a multi-hour run.

PQC-Bench Part 1 — measuring X25519MLKEM768 costs on a $0.04/hour Graviton3

asif naeem — Mon, 28 Sep 2026 19:46:30 +0000

There's a lot of discussion going on about post-quantum TLS. Both AWS and Cloudflare claim the overhead is minimal — but both are vendor-published, on infrastructure most people don't have. This is the starting post of a different attempt: an independent, reproducible benchmark of X25519MLKEM768 (the NIST-standardized hybrid PQ key exchange, FIPS 203) versus classical X25519. I ran it on two c7g.large EC2 instances in the same AWS zone. The full run cost less than a dollar.

Complete setup — Terraform, Gatling simulation, driver script, raw Gatling result files — is in the repo. This can be reproduced in around ~50 minutes for under $0.30 (based on my experience, accounting for the occasional disruption during a test).

Setup

Piece	Choice
Target	c7g.large spot, Ubuntu 24.04, nginx built from source against OpenSSL 3.5.0
Load generator	c7g.large spot, JDK 21, Gatling 3.15.1 (Java DSL)
Placement	Same subnet, same AZ (us-east-1) — cross-AZ latency would swamp the effect
Protocol	TLS 1.3 only
Cipher suites	TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256
Server cert	Self-signed ECDSA P-256
KEM (A/B knob)	X25519 vs X25519MLKEM768
Response body	3 bytes ("OK\n") — the point is handshake, not transfer
Session resumption	Disabled (fresh handshakes only)
Trials	3 per arm, 5 min each, 30 s warmup dropped

Note on the self-signed cert

The server serves an ECDSA cert, not an ML-DSA-65 one.

The reason: Gatling uses Netty's BoringSSL under the hood, and BoringSSL doesn't advertise ML-DSA-65 in its supported signature algorithms. If nginx only had an ML-DSA-65 cert to serve, BoringSSL wouldn't be able to complete the handshake at all.

This actually mirrors real-world PQ TLS in 2026: no public CA issues ML-DSA-65 certs. Everyone shipping "PQ TLS" today serves a classical cert with a hybrid KEM. This benchmark measures the KEM overhead under exactly that pattern.

First attempt: what didn't work

My first serious run was at 1000 req/s. The numbers were absurd:

Metric	Classical	PQ
min	1 ms	1 ms
mean	1,318 ms	1,230 ms
p99	6,440 ms	6,091 ms
max	7,648 ms	7,548 ms

Not "PQ is faster than classical" — that's not physically possible when the PQ arm does the same work as classical plus more crypto. The shape (min=1ms, mean=1300ms) is the fingerprint of client-side CPU saturation. 1000 fresh handshakes/sec on a 2-vCPU loadgen means each vCPU is doing 500 handshakes/sec of X25519 or ML-KEM math — beyond a c7g.large's capacity. Requests queue for CPU, means shoot into the seconds range, and any actual PQ vs classical delta gets swallowed by queuing noise.

Cross-check: PQ p99 across the 3 trials ranged 5892 → 6091 → 7623 ms. That trial-to-trial variance is bigger than any real signal I could measure — a red flag on its own.

Lesson: benchmark your load generator before you trust its numbers. Client-side CPU cost is easy to forget when the discussion is all about server overhead.

The real numbers, at 300 req/s

Dropping to 300 req/s puts the loadgen well inside its capacity envelope. Now I'm measuring the handshake itself.

Median of 3 trials, latency in milliseconds:

Metric	Classical (X25519)	PQ (X25519MLKEM768)	Overhead
min	1	1	—
mean	2	2	—
p50	1	2	+1 ms
p95	4	4	—
p99	5	8	+3 ms (+60%)
max	14	41	+27 ms

Trial-by-trial p99 (to show the variance honestly):

Trial	Classical p99	PQ p99
1	4	5
2	5	8
3	5	39

Trial 3's PQ p99 of 39 ms is a real outlier — likely a spot instance CPU steal event or a JVM GC pause, though I haven't isolated the cause yet. Something to nail down in Phase 2 with more trials.

What this tells me

Three findings worth stating:

1. In the common case, PQ overhead is essentially invisible. At 300 req/s on Graviton3, X25519MLKEM768 costs the same 2 ms mean handshake as classical X25519. p50 and p95 are the same at ms-resolution. If your SLO is "handshake under 50 ms", PQ vs classical is not what you should be worrying about.

2. The cost shows up in the tail. Median p99 grew from 5 ms to 8 ms. In one of three trials the PQ p99 was 39 ms — 8x what the median trial saw. This matches what I expected theoretically: KEM operations have more variance than raw X25519, and worst-case scheduling amplifies the difference.

3. This is a floor, not a ceiling. At sub-10 ms latencies, Gatling's integer-millisecond quantization hides sub-ms differences. The "no difference" reading at mean/p50/p95 may be masking real ~0.5 ms deltas. Higher-precision timing and higher throughput on beefier instances would tell more.

What I can't say from this run

How PQ overhead scales with concurrent connection count. All measurement here is at a fixed rate with the loadgen sized carefully to avoid saturation.
What happens with session resumption. Session resumption skips the KEM entirely. Real traffic is a mix — measuring just the fresh case is the worst case.
Whether Graviton3's specific silicon helps or hurts PQ. Would need x86 (c7i.large) or AMD (c6a.large) runs for comparison.
Anything about payload size scaling. Every response was 3 bytes.

All of these are Phase 2 targets.

Reproduce it

git clone https://github.com/asifmahbubnaeem/pqc-bench
cd pqc-bench
# Configure AWS profile + AMI IDs in terraform/bench/terraform.tfvars
make bench-up
make wait-ready
./scenarios/01-fresh-handshake-latency/run.sh 300 3
make bench-down

Wall time: ~50 min. AWS cost: ~$0.15. The raw Gatling result trees, including per-trial HTML reports and simulation.log files, can be found in results/2026-09-27-scenario-01-rate300/.

What's next

Phase 2 questions:

Payload sweep: 100 B / 1 KB / 100 KB / 1 MB response. Does handshake overhead disappear into transfer time?
Session resumption: Full mix, 0-RTT, 1-RTT. What's the effective overhead when 90% of connections resume?
Cross-architecture: Same benchmark on c7g (Graviton3, ARM), c7i (Intel Sapphire Rapids), c6a (AMD EPYC). Does the KEM math favor any one microarchitecture?
Concurrency sweep: 100 / 500 / 2000 concurrent connections at fixed rate — where does saturation actually hit, and does the answer differ for PQ vs classical?

I'll post those over the coming weekends. If there's a specific angle you'd want measured, contact me.

Data, methodology and all scripts live in the repo. Corrections and independent reruns very welcome — that's the whole point.

Draft assistance from Claude; all measurements, interpretations, and the setup work are mine and independently verified against the raw data in the repo.