AUTONOMY DIRECTORATE

🏠 Main

🏠 Home
⏰ Q-Day Countdown
0
Y
0
D
0
H
0
M
0
S
0
MS

🧪 Interactive Apps

🔐 Encrypt & Share 🔒 Encryption 🗜️ Compression 📄 PDF Tools 🎵 Music ✨ Quantum Sandbox 🔐 Challenge Mode 🔍 Regex Designer 🔬 PQC Scanner ⚡ HTTP/3 Scanner 🚀 WebTransport Test 🌐 Speed Test 📡 Telemetry Wall 🎲 Entropy

📰 News

📰 News
🗞️ Latest Headlines
Loading news...
Loading... • Just now

🛡️ PQ Crypta Proxy

🌐 Proxy Whitepaper 🖥️ Control Plane 🐙 GitHub 🎯 Red Team Tests

👤 Account

📝 Sign Up 🔑 Login 📊 Dashboard 🩺 Health Monitor 📡 System Telemetry 🚪 Logout

⟨ QUANTUM ERROR PORTAL ⟩

Navigate the Error Dimensions

PQ Crypta

The Post-Quantum Tail: the Fast KEMs Are the Jittery Ones

Every public benchmark ranks post-quantum algorithms by their typical time. We run all 35 as a live service, so we could measure something a point estimate can't: the distribution. Ranked by worst-case latency instead of median, the order turns over — the cheapest KEMs become the least predictable, and the heavyweight SPHINCS+ engines become the most reliable.

35 algorithms p50 / p95 / p99 tail-latency result Allan Riddel · PQ Crypta · 19 July 2026

A post-quantum benchmark that reports one number per algorithm is hiding the interesting part. The headline cost story is real and we cover it in full — an end-to-end operation stacks an API round-trip, the key-encapsulation math, and, where present, a signature, and SPHINCS+ signing dwarfs everything else. But the finding worth your time is one no spec sheet contains: measure the same operation hundreds of times through a real system and the distribution tells a different story than the median. Ranked by worst-case latency, the speed order inverts — the featherweight KEMs are the erratic ones, and the heavyweight signers are the metronomes.

Measured, not modelled Almost every post-quantum performance number you will read is an expectation: a reference implementation of a single primitive, benchmarked in isolation on native code with no I/O, reported as one figure. That is a useful number — and a different number from the one your users feel. We are in an unusual position to close that gap: we run these 35 algorithms as a live service, so we can measure the whole path a real request travels — client → API → crypto → back — and repeat it until the distribution is trustworthy. This page is what the algorithms actually cost in a running system, not what a spec sheet predicts.
What the data shows
  • The tail inverts the ranking — our headline result, and one only repeated measurement can reveal. The "fast" algorithms are the least predictable; the heavyweight SPHINCS+ engines are the most metronomic. A single-number benchmark hides this entirely — see the tail section for the p50/p95/p99 breakdown.
  • SPHINCS+ signing is the single biggest cost in the whole suite. Every engine that signs with SPHINCS+-SHA2-256s clusters at ~764ms encrypt — a 42× penalty over the ~18ms of the KEM-only engines.
  • Post-quantum key exchange is effectively free. ML-KEM-1024 finished a full round-trip in 45ms — statistically identical to the classical X25519 stack at 47ms.
  • Most per-operation time is network, not math. The browser-native classical baseline (no API) runs in 0.20ms; the moment an API call is involved every cheap algorithm jumps to the same ~45ms floor, regardless of which post-quantum primitive it uses.
  • Only three things genuinely cost crypto time: SPHINCS+ signing (~764ms), Classic McEliece key generation (293ms), and homomorphic key generation (2.12s). Everything else is dominated by the round-trip.
Contents
  1. How we measured
  2. The tail inverts the ranking
  3. The network floor
  4. The SPHINCS+ cliff
  5. KEMs, ranked and explained
  6. McEliece & homomorphic
  7. Measured vs. expected
  8. Full results table
Methodology

How we measured

Every number here comes from the same public tool anyone can run at /benchmark/. Each algorithm is exercised through a full generate keys → encrypt → decrypt round-trip against the production API. The page itself takes the median of 9 timed runs per phase and discards one warm-up run to absorb TLS/connection setup. We then ran that entire 35-algorithm suite 5 times end to end (163s, 156s, 115s, 166s, 161s wall-clock each) and took the median across runs.

Cross-run stability was high. The expensive clusters varied by well under 2% between runs, so the medians below are trustworthy to about the millisecond for the slow algorithms and to a few milliseconds for the fast ones.

For the distribution work (the next section) we ran a separate, dedicated collection: the same end-to-end operation repeated 60 times for each lightweight algorithm and 25 times for each heavyweight one, gently paced to respect the API. That gives us honest percentiles — with the fair caveat that at these sample sizes p95 is well-supported while p99 sits close to the single worst observation, so we treat p99 as "how bad the worst run in a hundred got," not a stable point.

One honesty caveat, stated up front. These runs were driven from a client close to the API, so the round-trip floor here is roughly 18ms per phase. A browser on a real home connection will see a higher, uniform floor (tens of milliseconds per phase) — but it moves every algorithm together, so the relative story on this page is unchanged. What we are isolating is the crypto cost that pokes above that floor.
Finding 1 · our headline result

The tail inverts the ranking

This is the finding no reference microbenchmark can give you, because it only exists once you measure the same operation hundreds of times through a real system. Rank the algorithms by their median and you get the cost story in the sections below. Rank them by their worst-case latency and the order turns over: the cheapest KEMs become the least reliable, and the slowest signers become the most reliable.

Two things happen as you climb from the median into the tail. First, the modest, consistent part: across the lightweight KEMs the 95th percentile sits at a median of 1.33× their own p50, versus 1.20× for the SPHINCS+ engines — the fast ones spread wider even at p95. Second, the dramatic part: a cheap operation is capable of a catastrophic single spike that a heavy one simply cannot produce.

One ML-KEM operation in 60 took 47× the median ML-KEM-1024's median round-trip was 40ms and its p95 was 190ms — but one run in 60 took 1.88s, roughly 47× its own median. Quantum-Lattice-Fusion did the same thing (201ms median, 2.17s worst). That spike is not the cryptography — it is a garbage-collection pause, a scheduler slice, or a network stall landing on an operation that has no compute cushion to hide behind. When the real work is ~15ms, a one-second stall is a 60× event.
No SPHINCS+ engine ever spiked Here is the mirror image, and the reason the ranking inverts: across every SPHINCS+ engine, the worst single run we recorded was at most 1.6× its own median — no exceptions, no multi-second outliers. Their ~764ms is dominated by deterministic hashing on the CPU, and an 800ms compute simply absorbs a 40ms jitter event that would be a 3× spike on a 15ms op. The heavyweight algorithm has a bounded tail by construction; the featherweight is exposed to every hiccup in the system.
Multi-KEM-Triple ✷p95 1.2× · worst 1×Multi-KEM ✷p95 1.2× · worst 1×Max-Secure-PQC-ZK ✷p95 1.1× · worst 1×ML-KEM-1024p95 4.7× · worst 47×X25519MLKEM768p95 1.4× · worst 2×Max-Secure-Pure-PQp95 1.6× · worst 2×AI-Synthesized-Crypto-Agilep95 1.7× · worst 2×

Bar = p95 as a multiple of that algorithm's own median; annotation adds the worst single run. ✷ = SPHINCS+ signed. The slow signers cluster tight; the fast KEMs fan out.

For anyone deploying this, the tail is the number that matters more than the median. A service with a p99 latency budget is better served by an algorithm whose cost is boring than one whose average is low but whose worst case is a wild card. Post-quantum choice, measured honestly, is as much about variance as about speed — and variance is exactly what a one-number spec sheet throws away.

Scope, honestly. These are 60/25-sample distributions from one client against one API, so a specific worst-run figure is a property of algorithm × our infrastructure on the day, not an intrinsic constant. The direction — cheap ops carry the fat, unbounded tail; heavy deterministic ops carry a tight, bounded one — is structural and would reproduce anywhere. The exact 47× would not.
Finding 2

The network floor hides most of the crypto

The browser-native classical baseline — ECDH P-256 in the Web Crypto API, no server involved — completes in 0.20ms. That is the speed of the math alone. Every other row on this page adds one thing: an API call. And the instant you do, the floor jumps to ~45ms and stays there for every cheap algorithm, whether it is doing X25519, ML-KEM-1024, or an X-Wing hybrid of both.

Classical ECDH P-2560.20msClassical47msML-KEM-102445msX25519MLKEM76836msPost-Quantum47msHQC-12856msMax-Secure-Pure-PQ49ms

Total round-trip, median of 5 suites. The first bar is browser-only; the rest each add one API call and converge on the same ~45ms floor.

This is the most important context on the page: for key exchange, post-quantum is not slower than classical in any way a user could feel. ML-KEM-1024's actual lattice operations take tens of microseconds; they are invisible next to the millisecond-scale cost of simply making the request. Anyone who tells you PQC key exchange is "too slow for production" is measuring their network, not the cryptography.

Finding 3 · the big cost

The SPHINCS+ cliff

Sort the whole suite by encrypt time and it splits cleanly into two populations with almost nothing in between: a low band around 18ms, and a high band around 764ms. The dividing line is a single design choice — whether the engine attaches a SPHINCS+-SHA2-256s signature (the FIPS 205 SLH-DSA hash-based scheme, "small" parameter set).

Why "s" is slow by design SPHINCS+ comes in s (small) and f (fast) flavours. The s variants shrink the signature by building a taller hash tree — which means vastly more hash evaluations at signing time. SPHINCS+-SHA2-256s trades signing speed for a compact signature on purpose. Our ~764ms is exactly what that trade-off looks like, and it is fixed cost: it does not shrink no matter how cheap the surrounding KEM is.

ML-KEM-102415msHQC-25639msMulti-KEM ✷781msMulti-KEM-Triple ✷745msQuad-Layer ✷764msMax-Secure-PQC-ZK ✷747msFN-DSA Dual-Signature ✷772msLattice-Code-Hybrid ✷823ms

Encrypt phase only. ✷ = attaches a SPHINCS+-SHA2-256s signature. The gap is the signature, not the KEM.

The clearest proof that this is the signature and not the KEM: Multi-KEM (one KEM), Multi-KEM-Triple (three KEMs), and Quad-Layer (four layers) all land within a few milliseconds of each other on encrypt (781ms, 745ms, 764ms). Adding two extra key encapsulations changed the total by less than the run-to-run noise, because each KEM is ~10ms and the shared SPHINCS+ signature is ~764ms. When one component is dozens of times the others, stacking the cheap ones is free.

The practical takeaway If you need a signature on every message and latency matters, SPHINCS+-256s is the wrong parameter set — reach for the f variant, or an ML-DSA / FN-DSA lattice signature (our FN-DSA-512 signs inside the ~18ms floor). SPHINCS+-256s earns its place only where signature size and hash-based conservatism matter more than signing latency — code signing, firmware, long-lived roots.
Finding 4

The KEMs, ranked — and why they land where they do

Strip out the signatures and the pure key-encapsulation mechanisms tell a tidy story that matches the math. Here is every KEM by total round-trip, split into key generation, encrypt and decrypt so you can see where each one spends its time.

ML-KEM-102445msX25519MLKEM76836msHQC-12855msFrodoKEM-97690msHQC-19285msFrodoKEM-1344105msHQC-256113ms\u2605 Dual-KEM parallel156msClassic McEliece775ms
Key generation Encrypt / encapsulate Decrypt / decapsulate

Median of 5 suites. Bars scaled to Classic McEliece, the outlier that makes the structure visible.

ML-KEM-1024 & X25519MLKEM76845ms
The structured-lattice standard (FIPS 203) and its TLS-ecosystem hybrid sit right on the network floor. Their operations are microsecond-scale; you are timing the request, not Kyber. The X-Wing hybrid adds an X25519 exchange for essentially zero measurable cost.
FIPS 203Level 5structured lattice
HQC-128 → 192 → 25656ms → 112ms
The code-based backup KEM (NIST's 2025 selection) is the first place crypto cost becomes visible: HQC's larger ciphertexts and encoding push encrypt and decrypt up as the level climbs. HQC-256 spends 50ms in decapsulation — the most of any single-KEM decrypt — which is inherent to the code-based construction, not overhead.
NIST 2025code-basedLevels 1/3/5
FrodoKEM-976 / 134488ms / 106ms
Unstructured-lattice, the conservative choice that refuses ring structure and pays for it in plain matrix arithmetic. Measurably slower than ML-KEM at the same security level — exactly the trade the BSI-recommended design makes: a bigger, slower KEM in exchange for the smallest possible set of algebraic assumptions.
unstructured latticeISO 18033-2BSI
Classic McEliece800ms
The oldest and most trusted code-based scheme, and the one KEM where key generation dominates (293ms). Building the Goppa-code keypair is genuinely expensive and the public key is enormous (~1 MB). But encapsulation and decapsulation are fast — so where keys are long-lived, its per-message cost is competitive.
slow keygenCategory 5ISO 18033-2
Finding 5

The two honest outliers

Post-ZK-Homomorphic is the slowest thing in the suite at 3.54s, and it should be. Almost all of that is key generation (2.12s) — building a fully-homomorphic evaluation key is one of the most expensive operations in applied cryptography, orders of magnitude beyond a KEM. This is not a regression; it is the price of computing on encrypted data, and it is in line with what FHE keygen costs everywhere.

Classic McEliece, covered above, is the other: a KEM whose cost lives entirely in keygen. Both outliers share a lesson — amortise the expensive phase. Generate the keypair or evaluation key once, reuse it across many messages, and the eye-watering headline number turns into a rounding error per operation.

2.12s
FHE key generation
293ms
McEliece key generation
764ms
SPHINCS+ signing
45ms
ML-KEM full round-trip
Finding 6 · measured vs. expected

Does this match what the field expects?

Every ranking here lines up with the published behaviour of these primitives — which is the point of measuring: to confirm the system behaves like the mathematics says it should.

ML-KEM ≈ classical ✓
Structured-lattice KEM operations are sub-millisecond in native code; reference benchmarks (e.g. liboqs) put ML-KEM-1024 keygen/encaps/decaps in the tens of microseconds. Our result — indistinguishable from X25519 once the network floor is added — is exactly right.
SPHINCS+-256s in the hundreds of ms ✓
Hash-based signing with the small parameter set is well known to run from hundreds of milliseconds to over a second depending on hardware. Our ~764ms sits squarely in that published range. Nothing anomalous — just an expensive signature doing what it advertises.
McEliece keygen ≫ its own encaps ✓
Classic McEliece is the textbook "slow keygen, fast use" KEM, with a megabyte-scale public key. Our 293ms keygen against 311ms/171ms encaps/decaps reproduces that shape precisely.
Frodo slower than ML-KEM ✓
Dropping ring structure for plain LWE matrices costs an order of magnitude in the literature. FrodoKEM-1344 at 106ms versus ML-KEM-1024 at 45ms — both Level 5 — is that trade-off, measured.

The one thing a naïve reading would get wrong is treating the ~764ms engines as "slow post-quantum encryption." They are not slow encryption; they are fast encryption plus a deliberately slow signature. Keeping those two costs separate is the whole point of this analysis.

Appendix

Full results — all 35 algorithms

Median of 5 full-suite runs; each cell is itself the median of 9 timed operations. Violet rows attach a SPHINCS+ signature. "CV" is the coefficient of variation of the total across runs — a stability check.

AlgorithmKey GenEncryptDecryptTotalRangeCV
Browser baseline
Classical ECDH P-2560.10ms0.10ms0.00ms0.20ms0.10ms–0.60ms0%
Classical (API)
Classical16ms16ms15ms47ms28ms–156ms26.2%
Password-Classical58ms58ms59ms179ms150ms–920ms89.1%
NIST KEM
X25519MLKEM76812ms12ms12ms36ms28ms–852ms24.5%
ML-KEM-102415ms15ms15ms45ms28ms–87ms21.4%
HQC-12816ms19ms20ms56ms43ms–752ms12.7%
FrodoKEM-97627ms34ms29ms88ms62ms–1.90s126%
HQC-19222ms29ms34ms93ms68ms–855ms16%
FrodoKEM-134432ms38ms35ms106ms84ms–156ms9.3%
HQC-25624ms39ms50ms112ms101ms–223ms16.1%
Classic McEliece293ms311ms171ms800ms567ms–1.79s12.3%
FN-DSA sig
FN-DSA Transition-Stack26ms16ms16ms59ms38ms–105ms12.6%
FN-DSA ZK-Stack23ms17ms16ms59ms40ms–101ms17%
FN-DSA-512-Compact24ms18ms17ms60ms39ms–79ms7%
FN-DSA FP-Hardened39ms17ms15ms72ms54ms–120ms9.7%
FN-DSA-1024-Security47ms18ms22ms88ms53ms–134ms16.5%
FN-DSA Dual-Signature ✷79ms772ms17ms868ms824ms–1.73s4.1%
Hybrid/multi
Post-Quantum14ms17ms16ms47ms30ms–785ms20.6%
Hybrid16ms22ms17ms53ms32ms–88ms18.3%
Multi-Algorithm ✷55ms743ms20ms817ms784ms–1.86s6.7%
Multi-KEM-Triple ✷54ms745ms19ms818ms776ms–1.51s2.1%
Multi-KEM ✷54ms781ms16ms854ms777ms–1.52s3.5%
Lattice-Code-Hybrid ✷140ms823ms43ms999ms892ms–4.21s14.3%
Max-secure
Max-Secure-Pure-PQ15ms17ms18ms49ms33ms–142ms13.7%
Max-Secure-Lightweight16ms16ms18ms50ms34ms–1.90s13.4%
Max-Secure-Hybrid-Transition16ms19ms18ms53ms39ms–2.23s14.9%
Max-Secure-Crypto-Agile43ms18ms19ms80ms51ms–150ms22.2%
Max-Secure-Stateless59ms16ms19ms93ms71ms–2.25s19.6%
Max-Secure-PQC-ZK ✷58ms747ms20ms822ms772ms–2.72s9%
Advanced
AI-Synthesized-Crypto-Agile16ms17ms15ms52ms32ms–2.13s32.4%
PQ3-Stack17ms19ms18ms55ms32ms–1.92s16.8%
Quantum-Resistant-Consensus47ms21ms18ms81ms59ms–2.67s28.4%
Entropy-Orchestrated39ms35ms15ms90ms64ms–2.11s10.4%
Quantum-Lattice-Fusion70ms84ms44ms199ms166ms–2.32s16%
Post-ZK-Homomorphic2.12s536ms901ms3.54s3.04s–6.96s6.6%
PQ Crypta
\u2605 Dual-KEM parallel35ms52ms69ms157ms113ms–1.95s14.7%
Maximum
Quad-Layer ✷58ms764ms22ms875ms781ms–2.73s4.7%
Reproduce this yourself. Open /benchmark/ and click Run. Your absolute numbers will differ with your distance to the API, but the shape — a flat floor for the KEMs, a cliff at SPHINCS+, and two keygen-heavy outliers — is the invariant. ✷ marks the 7 engines that sign with SPHINCS+-SHA2-256s.