Post-Quantum Cryptography Benchmarks 2026: ML-KEM, ML-DSA, SLH-DSA, FN-DSA, HQC and LMS Measured
This is an original benchmark study of every post-quantum cryptography algorithm QNSQY ships, measured on one machine, on one day, with the method published alongside the numbers. It covers the NIST-standardized lattice schemes (ML-KEM, ML-DSA), the hash-based schemes (SLH-DSA, LMS), the NTRU-lattice signature FN-DSA (Falcon), and the code-based KEM HQC, plus the hybrid variants that pair them with X25519 and Ed25519. If you are planning a PQC migration and want a concrete feel for what these algorithms cost in microseconds and bytes, this page is the raw data.
Method, before the numbers
Numbers without a method are marketing. Here is ours, in full:
- Date: 2026-07-30.
- Host: AMD Ryzen 7 7735HS (a mainstream laptop CPU, not a tuned server), Fedora Linux, 32 GB RAM.
- What ran: our in-process benchmark harness, calling the exact same implementation code paths the shipped
qnsqybinary uses (qnsqy v7.2.38 codebase), compiled with the same fat-LTO optimized release profile as the production build, Rust toolchain rustc 1.95.0-nightly. - How measured: single-threaded, adaptive iteration counts per scheme, reported values are medians. Each scheme runs isolated so one failure cannot skew another. The full sweep completed in 23.3 seconds of wall-clock.
- Sizes: public key, secret key, signature, and ciphertext sizes are read from the actual byte buffers produced, not copied from a spec table. They match the parameter sizes published in FIPS 203, FIPS 204, and FIPS 205 byte-for-byte.
What this study is not: it is not a constant-time analysis, not a cross-CPU survey, and not a claim about your hardware. Absolute timings will differ on your machine; the relationships between schemes (which is what you need for algorithm selection) are stable across modern x86-64 hardware.
Signature schemes: keygen, sign, verify
Times are medians. us = microseconds, ms = milliseconds. NIST level is the claimed security category (L1 ≈ AES-128, L3 ≈ AES-192, L5 ≈ AES-256).
| Algorithm | Family | NIST | keygen | sign | verify | pk (B) | sk (B) | sig (B) |
|---|---|---|---|---|---|---|---|---|
| ML-DSA-44 | ML-DSA (lattice) | L2 | 229.5 us | 261.5 us | 168.5 us | 1,312 | 2,560 | 2,420 |
| ML-DSA-65 | ML-DSA (lattice) | L3 | 377.4 us | 869.3 us | 272.4 us | 1,952 | 4,032 | 3,309 |
| ML-DSA-87 | ML-DSA (lattice) | L5 | 593.1 us | 641.6 us | 452.3 us | 2,592 | 4,896 | 4,627 |
| FN-DSA-512 (Falcon) | FN-DSA (NTRU) | L1 | 7.178 ms | 219.9 us | 53.6 us | 897 | 1,281 | 651 |
| FN-DSA-1024 (Falcon) | FN-DSA (NTRU) | L5 | 21.660 ms | 425.3 us | 95.0 us | 1,793 | 2,305 | 1,275 |
| SLH-DSA-128s | SLH-DSA (hash) | L1 | 36.071 ms | 278.433 ms | 266.7 us | 32 | 64 | 7,856 |
| SLH-DSA-128f | SLH-DSA (hash) | L1 | 573.0 us | 14.256 ms | 871.4 us | 32 | 64 | 17,088 |
| SLH-DSA-192s | SLH-DSA (hash) | L3 | 63.975 ms | 726.428 ms | 644.6 us | 48 | 96 | 16,224 |
| SLH-DSA-192f | SLH-DSA (hash) | L3 | 1.000 ms | 30.424 ms | 1.583 ms | 48 | 96 | 35,664 |
| SLH-DSA-256s | SLH-DSA (hash) | L5 | 37.052 ms | 658.366 ms | 818.4 us | 64 | 128 | 29,792 |
| SLH-DSA-256f | SLH-DSA (hash) | L5 | 2.318 ms | 55.886 ms | 1.480 ms | 64 | 128 | 49,856 |
| LMS SHA-256 H5/W1 | LMS (hash, stateful) | L5 | 1.770 ms | 1.783 ms | 26.2 us | 60 | 48 | 8,688 |
| LMS SHA-256 H10/W2 | LMS (hash, stateful) | L5 | 47.411 ms | 47.497 ms | 23.8 us | 60 | 48 | 4,624 |
| ML-DSA-87 + Ed25519 hybrid | Hybrid | L5 | 615.7 us | 4.780 ms | 495.6 us | 2,624 | 4,928 | 4,691 |
| FN-DSA-1024 + Ed25519 hybrid | Hybrid | L5 | 20.061 ms | 487.8 us | 145.7 us | 1,825 | 2,337 | 1,336 |
KEM schemes: keygen, encapsulate, decapsulate
| Algorithm | Family | NIST | keygen | encap | decap | pk (B) | sk (B) | ct (B) |
|---|---|---|---|---|---|---|---|---|
| ML-KEM-512 | ML-KEM (lattice) | L1 | 46.7 us | 51.1 us | 56.8 us | 800 | 1,632 | 768 |
| ML-KEM-768 | ML-KEM (lattice) | L3 | 73.6 us | 76.8 us | 83.5 us | 1,184 | 2,400 | 1,088 |
| ML-KEM-1024 | ML-KEM (lattice) | L5 | 110.5 us | 110.5 us | 117.5 us | 1,568 | 3,168 | 1,568 |
| HQC-128 | HQC (code-based) | L1 | 2.015 ms | 4.079 ms | 6.485 ms | 2,249 | 2,305 | 4,433 |
| HQC-192 | HQC (code-based) | L3 | 6.213 ms | 12.414 ms | 19.136 ms | 4,522 | 4,586 | 8,978 |
| HQC-256 | HQC (code-based) | L5 | 11.307 ms | 22.657 ms | 35.215 ms | 7,245 | 7,317 | 14,421 |
| ML-KEM-512 + X25519 hybrid | Hybrid | L1 | 81.1 us | 144.8 us | 116.8 us | 832 | 1,632 | 800 |
| ML-KEM-1024 + X25519 hybrid | Hybrid | L5 | 143.7 us | 204.7 us | 178.7 us | 1,600 | 3,168 | 1,600 |
| HQC-256 + X25519 hybrid | Hybrid | L5 | 11.280 ms | 22.941 ms | 35.261 ms | 7,277 | 7,317 | 14,453 |
What the numbers actually tell you
ML-KEM is effectively free. A complete ML-KEM-768 key exchange (keygen + encapsulate + decapsulate) costs under a quarter of a millisecond on a laptop CPU. Performance is not a reason to delay post-quantum key exchange, and it has not been for years. This is why hybrid ML-KEM handshakes already run at internet scale in browsers and CDNs.
ML-DSA is the balanced default for signatures. Sub-millisecond keygen, sign, and verify at every security level, with signatures in the 2.4 to 4.6 KB range. If you need one general-purpose post-quantum signature today, ML-DSA is the boring, correct answer, which is why it is QNSQY's default signing family.
FN-DSA (Falcon) trades keygen pain for tiny, fast signatures. Keygen is the slowest of the lattice schemes (7 to 22 ms), but signatures are the smallest of any post-quantum scheme here (651 bytes at L1) and verification is the fastest after LMS. That profile fits certificates and firmware: generate keys rarely, verify constantly. The catch: Falcon's signing path needs careful floating-point implementation, which is why FIPS 206 is still being finalized.
SLH-DSA is a deliberate tradeoff, not a slow ML-DSA. The "s" (small) variants take hundreds of milliseconds to sign but produce the smaller signatures; the "f" (fast) variants sign 10 to 20 times quicker but roughly double the signature size. In exchange you get the most conservative security assumption in the standardized set: hash functions only. Keys are almost comically small (32 to 128 bytes).
LMS has the fastest verification we measured (about 24 to 27 us) and small keys, but it is stateful: signing the same one-time key twice destroys security. QNSQY's stateless sign API refuses to sign with LMS precisely because of that hazard; a dedicated stateful signing path with state tracking is required. LMS belongs in firmware-update pipelines, not in general-purpose signing.
Code-based HQC is the diversity hedge. Two to three orders of magnitude slower than ML-KEM with far larger ciphertexts. You choose HQC because it does not rest on lattice assumptions, not because of its performance. For most deployments it is the backup plan, and NIST selected it in 2025 for exactly that role.
Hybrids cost almost nothing. Adding X25519 to ML-KEM-1024 adds roughly 30 to 90 microseconds per operation. Adding Ed25519 to ML-DSA-87 is similarly cheap on verify. The insurance of a second, battle-tested assumption costs less than a database round trip, which is why hybrid is QNSQY's default mode.
Notes and caveats
- LMS H15/W4 and H20/W8 are shipped in QNSQY but intentionally skipped in the sweep: their keygen builds a Merkle tree of 2^15 / 2^20 one-time keys and can take tens of seconds to minutes. H5/W1 and H10/W2 characterize the family. The H10/W2 signature (4,624 B) is smaller than H5/W1 (8,688 B) because of the Winternitz parameter, a nice example of LMS tuning being unintuitive.
- The secret-key sizes reported for ML-DSA are the expanded on-disk representation, which is why they exceed the FIPS 204 seed size.
- Hybrid rows include the classical component; the delta against the pure row of the same level is the classical overhead.
- Medians on one warm machine. If you need audited performance claims for procurement, run the measurement on your own reference hardware; the point of publishing the method is that you can.
How this compares to other public benchmarks
We deliberately publish only numbers we measured ourselves. For cross-checking, the public reference points are SUPERCOP, the Open Quantum Safe / liboqs project, and the NIST signatures zoo, which aggregate results across many CPUs and implementations. Our size figures agree with the published FIPS 203/204/205 parameter sets exactly; timing relationships between families are consistent with what those projects report, with absolute values scaled by hardware.
Frequently Asked Questions
Is ML-KEM fast enough to replace classical key exchange?
Yes. On a mainstream laptop CPU, a full ML-KEM-768 exchange (keygen, encapsulate, decapsulate) completes in under 250 microseconds. That is comparable to or faster than the classical RSA handshakes it replaces, which is why hybrid ML-KEM is already deployed at internet scale by major browsers and CDNs.
Which post-quantum signature algorithm is fastest?
It depends on the operation. ML-DSA is the best all-rounder, staying sub-millisecond for keygen, sign, and verify. LMS verification was the single fastest operation we measured, around 24 microseconds, but LMS is stateful and unsafe for general-purpose signing. FN-DSA verifies fastest among stateless schemes but pays 7 to 22 ms at keygen.
Why are SLH-DSA signatures so slow to create?
SLH-DSA builds signatures from thousands of hash computations instead of algebraic structure. The "s" variants take hundreds of milliseconds to sign because they optimize for smaller signatures. In exchange, security rests only on the hash function, the most conservative assumption available in the NIST-standardized set.
What hardware were these benchmarks run on?
One machine: an AMD Ryzen 7 7735HS laptop CPU running Fedora Linux, single-threaded, medians of adaptive iteration counts, using the same optimized production build profile as the shipped QNSQY binary (v7.2.38 codebase, 2026-07-30). Your absolute numbers will differ; the relationships between algorithms will not.
Do hybrid modes slow down post-quantum encryption?
Barely. Pairing ML-KEM-1024 with X25519 added 30 to 90 microseconds per operation in our measurements, and ML-DSA-87 with Ed25519 added under 50 microseconds on verify. The redundancy of a second, independently trusted assumption costs less than a single network round trip.
Reproduce or challenge this
The method above is complete: same-day date, exact CPU, build profile, measurement discipline, and byte-exact size validation against FIPS 203/204/205. If you measure something materially different on comparable hardware, or you think the method hides something, email [email protected] and we will publish the correction. Related reading: ML-KEM explained, ML-DSA vs SLH-DSA, FN-DSA (Falcon) explained, LMS stateful signatures, HQC explained.