DEV Community: asif naeem

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.