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.
Updated 2026-08-20: we re-ran the sweep on the v7.2.39 codebase and extended it to all 44 shipped algorithm variants plus classical baselines (ECDSA-P256, Ed25519, X25519, ECDH-P256) measured by the same harness on the same machine. Headlines: a full ML-KEM-512 key exchange measured faster than X25519; Falcon signing is now deliberately slower after a constant-time hardening fix; and the LMS H20/W8 tree that the July run skipped took 431 seconds of keygen. Jump to the update. The July tables below are preserved as the original record; only a dagger marker was added to the two superseded Falcon signing cells.
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 |
† Superseded for v7.2.39 and later: QNSQY shipped a constant-time Falcon signing fix on 2026-08-16 that makes signing deliberately slower. See the 2026-08-20 update for current numbers.
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.
Update 2026-08-20: full sweep, classical baselines, and a Falcon correction
We re-ran everything on 2026-08-20 (same machine, same rustc, same fat-LTO production build profile, now on the shipped v7.2.39 codebase) and extended the sweep to all 44 algorithm variants QNSQY ships: every SLH-DSA SHAKE parameter set, every Ed25519 hybrid, every X25519 hybrid, and the LMS H15/W4 and H20/W8 trees the July run skipped. We also measured classical baselines with the same harness in the same run: Ed25519, ECDSA-P256, X25519, and ECDH-P256 (pure-Rust implementations; the P-256 crates are bench-only additions, and QNSQY does not ship ECDSA). Total sweep wall-clock: 925.0 seconds, of which the LMS H20/W8 Merkle tree alone consumed about 863.
The Falcon correction, first
The July table above shows FN-DSA-512 signing at 219.9 us. That number is now obsolete, and the reason matters more than the number: v7.2.39 (2026-08-16) shipped a constant-time Falcon signing fix. Signing now measures 3.129 ms (FN-DSA-512) and 6.936 ms (FN-DSA-1024) on the same machine, roughly 14x and 16x slower. That is the price of closing a timing side channel in the floating-point signing path, and we consider it non-negotiable for a security tool. Verification is unaffected (39.4 us and 70.0 us, still the fastest stateless post-quantum verify we measure). If a benchmark page never gets slower, it is not being honest with you.
Classical baselines, same harness, same machine, same run
Signatures:
| Algorithm | keygen | sign | verify | pk (B) | sig (B) |
|---|---|---|---|---|---|
| Ed25519 (classical) | 25.3 us | 28.1 us | 38.1 us | 32 | 64 |
| ECDSA-P256 (classical) | 105.3 us | 123.3 us | 201.2 us | 33 | 64 |
Key exchange (encap = ephemeral keygen + DH, decap = one DH, i.e. what a KEM does):
| Algorithm | keygen | encap | decap | pk (B) | ct (B) |
|---|---|---|---|---|---|
| X25519 (classical) | 24.2 us | 69.7 us | 47.6 us | 32 | 32 |
| ECDH-P256 (classical) | 105.0 us | 203.2 us | 104.4 us | 33 | 33 |
Baseline caveat, stated up front: these are pure-Rust implementations (the RustCrypto p256 crate, added bench-only, and the dalek Ed25519/X25519 crates QNSQY already ships inside its hybrids), chosen so the classical rows are built exactly like our PQC rows. OpenSSL's assembly-optimized P-256 is typically several times faster than the pure-Rust p256 crate, so treat the P-256 rows as a Rust-ecosystem baseline, not the fastest possible classical code. The X25519/Ed25519 (dalek) implementations are mature and representative.
The comparison migration planners actually ask for
Baseline: ECDSA-P256 + X25519, the pre-quantum status quo. Sig CPU = sign + verify. KEX CPU = keygen + encap + decap (a TLS-1.3-style ephemeral exchange). Wire bytes = KEM public key + KEM ciphertext + signature, certificates excluded. Baseline totals: 466.0 us combined CPU, 128 bytes on the wire. All numbers from the same 2026-08-20 run, medians.
| Combination | sig CPU | KEX CPU | combined | vs baseline | wire bytes | vs baseline |
|---|---|---|---|---|---|---|
| ECDSA-P256 + X25519 (baseline) | 324.5 us | 141.5 us | 466.0 us | 1.0x | 128 B | 1.0x |
| ML-DSA-44 + ML-KEM-512 | 603.2 us | 116.9 us | 720.1 us | 1.5x | 3,988 B | 31x |
| ML-DSA-65 + ML-KEM-768 | 1,177.1 us | 167.1 us | 1,344.2 us | 2.9x | 5,581 B | 44x |
| ML-DSA-87 + ML-KEM-1024 | 782.9 us | 240.2 us | 1,023.1 us | 2.2x | 7,763 B | 61x |
| ML-DSA-44+Ed25519 / ML-KEM-512+X25519 (QNSQY default style) | 523.6 us | 240.9 us | 764.5 us | 1.6x | 4,116 B | 32x |
| ML-DSA-65+Ed25519 / ML-KEM-768+X25519 | 2,250.7 us | 298.5 us | 2,549.2 us | 5.5x | 5,709 B | 45x |
| ML-DSA-87+Ed25519 / ML-KEM-1024+X25519 | 2,291.6 us | 369.5 us | 2,661.1 us | 5.7x | 7,891 B | 62x |
Three things fall out of this table:
1. Post-quantum key exchange is not slower than classical. On this machine it is faster. A full ML-KEM-512 exchange (116.9 us) beats X25519 (141.5 us) in the same run. ML-KEM-768 lands within about 18% of X25519. Even the ML-KEM-1024+X25519 hybrid exchange (369.5 us) is faster than plain classical ECDH-P256 (412.6 us).
2. Signatures stay in the same order of magnitude. ML-DSA-44 and ML-DSA-65 verify faster than our ECDSA-P256 baseline verifies (123.1 and 198.8 us vs 201.2 us). Signing costs more than Ed25519, but pure ML-DSA signing stays sub-millisecond at every security level.
3. The real migration cost is bytes, not CPU. 31 to 62 times more wire data per handshake. If your link can absorb 4 to 8 KB per handshake, compute was never the blocker.
New rows measured for the first time
Signature schemes (medians unless marked; LMS H15/H20 keygen and sign are single-shot n=1 because each builds the full Merkle tree):
| Algorithm | NIST | keygen | sign | verify | pk (B) | sig (B) |
|---|---|---|---|---|---|---|
| SLH-DSA-SHAKE-128s | L1 | 176.630 ms | 1.352 s | 1.272 ms | 32 | 7,856 |
| SLH-DSA-SHAKE-128f | L1 | 2.753 ms | 64.948 ms | 3.845 ms | 32 | 17,088 |
| SLH-DSA-SHAKE-192s | L3 | 257.511 ms | 2.319 s | 1.860 ms | 48 | 16,224 |
| SLH-DSA-SHAKE-192f | L3 | 3.969 ms | 103.898 ms | 5.455 ms | 48 | 35,664 |
| SLH-DSA-SHAKE-256s | L5 | 168.643 ms | 2.014 s | 2.882 ms | 64 | 29,792 |
| SLH-DSA-SHAKE-256f | L5 | 10.528 ms | 212.642 ms | 5.645 ms | 64 | 49,856 |
| LMS SHA-256 H15/W4 (n=1) | L5 | 1.787 s | 1.790 s | 38.1 us | 60 | 2,672 |
| LMS SHA-256 H20/W8 (n=1) | L5 | 431.667 s | 431.024 s | 211.1 us | 60 | 1,776 |
| FN-DSA-512 (v7.2.39, constant-time signing path) | L1 | 11.556 ms | 3.129 ms | 39.4 us | 897 | 655 |
| FN-DSA-1024 (v7.2.39, constant-time signing path) | L5 | 25.441 ms | 6.936 ms | 70.0 us | 1,793 | 1,274 |
The SHAKE story: roughly 4.2 to 7.3 times slower than their SHA2 twins across keygen, sign, and verify, with byte-identical key and signature sizes (the bytes themselves differ; SHAKE and SHA2 parameter sets are not interchangeable). The reason is hardware: this CPU accelerates SHA-2 (SHA-NI) and runs Keccak in software. Pick SHA2 parameter sets unless an interoperability requirement says SHAKE.
The LMS story is the whole Winternitz trade in one column: signatures shrink from 8,688 B (H5/W1) to 4,624 B (H10/W2) to 2,672 B (H15/W4) to 1,776 B (H20/W8), while keygen and signing cost explodes from about a millisecond to about seven minutes. LMS verify at H5 through H15 (17 to 38 us) stays the fastest verification we measure anywhere; H20/W8 verify is 211.1 us.
KEM hybrids measured for the first time:
| Algorithm | NIST | keygen | encap | decap | pk (B) | ct (B) |
|---|---|---|---|---|---|---|
| ML-KEM-768 + X25519 hybrid | L3 | 75.7 us | 120.7 us | 102.1 us | 1,216 | 1,120 |
| HQC-128 + X25519 hybrid | L1 | 1.408 ms | 2.883 ms | 4.494 ms | 2,281 | 4,465 |
| HQC-192 + X25519 hybrid | L3 | 4.252 ms | 8.609 ms | 13.136 ms | 4,554 | 9,010 |
Internal consistency check
If the harness is honest, the hybrid-minus-pure ML-KEM deltas should independently reproduce the standalone X25519 measurements. They do: keygen deltas of 18.9 to 23.0 us against a standalone X25519 keygen of 24.2 us; encap deltas of 63.2 to 65.8 us against 69.7 us; decap deltas of 41.7 to 42.7 us against 47.6 us. Encap and decap deltas agree with the standalone row within 13%; keygen within 22%.
Cross-run honesty notes
- Most schemes measured 15 to 30% faster than in July on unchanged code paths (for example, ML-KEM-512 keygen 46.7 to 38.1 us). Same CPU, same compiler: that spread is host state (thermal and load), and it is exactly why we tell you to trust the relationships between schemes, not the absolute microseconds.
- ML-DSA signing medians are noisy across batches because signing is a rejection-sampling loop: ML-DSA-44 signing measured 261.5 us in July and 480.1 us in August. Budget for the range, not the best case.
- Falcon signature sizes differ by a few bytes between runs (651 vs 655 B) because Falcon signatures are variable-length by design. Sizes for every fixed-size scheme are byte-identical across both runs and match FIPS 203/204/205 exactly.
How our numbers sit against public implementations
These are published third-party figures, on their hardware, with their implementations. We did not measure them, units and machines differ, so read patterns, not decimals.
| Operation | QNSQY v7.2.39 (pure Rust, Ryzen 7 7735HS) | Published reference | Source |
|---|---|---|---|
| ML-KEM-768 keygen / encap / decap | 52.8 / 54.9 / 59.4 us | OpenSSL 3.5: ~31.4 / 17.9 / 28.3 us. wolfSSL 5.8.0 (asm): ~6.1 / 6.6 / 5.0 us | wolfSSL benchmark post, May 2025, unspecified x86_64 Linux PC |
| ML-KEM vs X25519 relationship | ML-KEM-512 full exchange faster than X25519 (116.9 vs 141.5 us) | ML-KEM-768 ~29-45k ops/s vs X25519 ~19k ops/s on their fleet; "even ML-KEM-1024 is typically significantly faster than X25519" | Cloudflare, "The state of the post-quantum Internet", March 2024 |
| ML-DSA-44/65/87 sign | 480.1 / 978.3 / 459.0 us | 61.9 / 107.5 / 136.0 us | PQShield NIST signatures zoo, Intel i7-12650H, medians of 1,000 |
| ML-DSA-44/65/87 verify | 123.1 / 198.8 / 323.9 us | 27.2 / 46.1 / 73.0 us | PQShield NIST signatures zoo |
| Falcon-512/1024 sign | 3.129 / 6.936 ms (constant-time signing path) | 224.4 / 448.2 us | PQShield NIST signatures zoo |
| SLH-DSA-SHAKE-128s / 192s / 256s sign | 1.352 / 2.319 / 2.014 s | 0.956 / 1.61 / 1.47 s | PQShield NIST signatures zoo |
What agrees everywhere: ML-KEM is as fast as or faster than X25519 (our same-machine measurement and Cloudflare's fleet data both show it), SLH-DSA "s" signing is hundreds of milliseconds to seconds on every stack, Falcon verification is uniformly fast, and the sizes are byte-identical across all sources because FIPS fixes them. Where we sit: our pure-Rust, memory-safe stack runs roughly 2 to 12 times slower than hand-tuned AVX2 assembly on lattice math, depending on the operation. That is a real gap and we publish it rather than hide it; every operation that matters still completes in microseconds to low milliseconds, and file encryption amortizes one KEM plus one signature over an entire file. Our Falcon signing is additionally slower than reference figures on purpose: the constant-time hardening described above, which published reference numbers do not price in. For the deepest public data, cross-check SUPERCOP, Open Quantum Safe / liboqs, the NIST signatures zoo, and TII's PQ-SORT.
The full 48-row dataset with the raw, timestamped sweep output is available on request: [email protected].
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, as low as 17 microseconds for the smaller trees, but LMS is stateful and unsafe for general-purpose signing. FN-DSA verifies fastest among stateless post-quantum schemes but pays roughly 7 to 25 ms at keygen across our two runs.
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, 32 GB RAM, single-threaded, medians of adaptive iteration counts, using the same optimized production build profile as the shipped QNSQY binary. Two runs are published: the original 2026-07-30 run (v7.2.38 codebase) and the extended 2026-08-20 run (v7.2.39, all 44 shipped variants plus classical baselines), both on the same machine. 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 roughly 20 to 95 microseconds per operation across our two runs, 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.
How does post-quantum performance compare to ECDSA-P256 and X25519?
We measured both with the same harness on the same machine in the same run (2026-08-20). A full ML-KEM-512 key exchange was faster than X25519 (116.9 vs 141.5 microseconds), and ML-DSA-44 and ML-DSA-65 verified faster than ECDSA-P256. A complete ML-DSA-87 + ML-KEM-1024 handshake costs about 2.2 times the classical CPU time but 61 times the wire bytes. The migration cost of post-quantum cryptography is bandwidth, not compute.
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.