Post-Quantum: Lattice or Hash-Based (one question, two right answers)

What it is

A decision framework for post-quantum signatures built from interviews with NIST/CNSA standard designers (Peter Schwabe, Bas Westerbaan, Filippo Valsorda, Thom Wiggers, Michael Baentsch), with concrete, dated specifics beyond the lattice-vs-hash framing already summarized: hard numbers, a timing formula, and named gaps in current tooling.

How it works

Two system properties determine the answer, not scheme preference: (1) where verification happens — CPU (bytes/verifier maturity dominate) vs. inside a proof circuit (constraint count dominates, hashing is nearly free) — and (2) whether signatures travel alone with a stored key or arrive in crowds needing aggregation. Mosca's inequality is reframed for signatures as v + y > z (verification lifetime + migration time > time to cryptanalytically-relevant quantum computer) to decide migration urgency per use case rather than uniformly.

Preconditions / Affected

• Anyone choosing between ML-DSA (FIPS 204), SLH-DSA (FIPS 205), or planning for FN-DSA/Falcon (FIPS 206, still draft as of Aug 28, 2025, final expected late 2026/early 2027).
• CNSA 2.0 binds only National Security Systems: ML-DSA-87 for general signatures; LMS/XMSS (stateful, SP 800-208) specifically for firmware/software signing, with all deployed firmware required on CNSA 2.0 signatures by 2030.
• Stateful schemes (XMSS/LMS) are only safe where state management is already mandatory (hardware-enforced counters, or Ethereum's validator keystore, EIP-8310) — not for consumer wallets.

What to do

• Treat verifier readiness as a hard gate, not a formality: as of September 2026, Project Wycheproof has adversarial test vectors for ML-KEM and ML-DSA but not SLH-DSA — only conformance (CAVP/ACVP) vectors exist for it, which don't catch adversarial edge cases. Re-check this before leaning on SLH-DSA's "conservative" framing, since it can flip which scheme is actually riskier to deploy.
• For TLS-adjacent systems, note Go 1.27 (Aug 2026) shipped crypto/mldsa (FIPS 204) wired into crypto/x509/crypto/tls — this closed a gate Sigstore had set as a precondition for PQ signing adoption.
• If choosing hybrid (classical+PQ) vs. pure PQ signatures: NSA's CNSA 2.0 FAQ explicitly argues against hybrid as default (extra interop burden, second future migration, added implementation complexity) while permitting it only for technical constraints like IKEv2 key-size limits — contradicting the common "hybrid now" default advice.
• For blockchain/on-chain contexts: Algorand is the only live deployment of a NIST-track scheme — Falcon-1024 (pre-standard, not FIPS 206) signs State Proofs since 2022, with a native falcon_verify AVM opcode added September 2024, and native Falcon-1024 PQ accounts activated on mainnet August 2026.
• Ethereum's concrete roadmap artifacts to track: EIP-8292 (consensus aggregation via zkVM proofs over leanXMSS), EIP-8310 (validator keystore for state management), EIP-8288 (June 3, 2026 proposal for scheme-agnostic block-level aggregation via recursive STARKs).

Caveats

• CNSA 2.0 v2.1 now also approves ML-DSA for firmware signing; LMS/XMSS remain preferred only because validated implementations are commercially available today, not as a permanent mandate.
• Falcon-1024 on Algorand is pre-standard, not FIPS 206 FN-DSA — the article explicitly warns against reading this as "FN-DSA in production."
• The NIST onramp (round 3, nine candidates including MAYO, SQIsign, HAWK) won't produce a standard before roughly 2028 — not a near-term option.