From Algebra to Noise: Why Post-Quantum Cryptography Looks Different

What it is

OpenZeppelin Security's deep-dive on post-quantum cryptography for tokenized finance (dated Sept 14, 2026), aimed at custody/treasury/governance leads. The summary covers the Shor/Grover/NIST conceptual arc; what it omits is the concrete engineering cost figures and the operational playbook — which are the parts an engineer deciding whether to act actually needs.

The numbers that drive the decision

The migration is not free, and the page quantifies why:

• Signatures: raw secp256k1 ECDSA is tens of bytes; ML-DSA (Dilithium) is measured in kilobytes; SLH-DSA (SPHINCS+) reaches tens of kilobytes depending on parameters. Falcon/FN-DSA is the compact option once standardized.
• Public keys: ML-DSA public keys are ~1.3 KB versus 33 bytes for compressed secp256k1 — significant for account-abstraction wallets that store keys on-chain.
• Verification: lattice verification is computationally heavier than ECDSA, compounding already-expensive on-chain gas costs.

NIST finalized the standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA); Falcon (FN-DSA) and HQC selected for future standardization.

The core threat framing

"Expose-now, forge-later" — the on-chain analogue of harvest-now-decrypt-later. Once an authority-bearing public key is permanently on-chain, a future CRQC may recover the private key and forge authorizations unless assets have already migrated. Already-exposed EOAs and forgotten UTXOs cannot be retrofitted — they can only be moved before Q-Day. Base-layer schemes (secp256k1 on both chains) are fixed by consensus, so no institution can unilaterally fix them; this is coordination-bound, systemic risk.

What to do

The page gives a concrete 7-step institutional playbook to start in 2026:

1. Cryptographic asset inventory — locate all ECDSA/EdDSA/RSA/BLS use, key exchange, TLS/SSH certs, pairing-based crypto, contract signature verification, off-chain approval keys.
2. Classify public-key exposure per wallet/key.
3. Identify authority concentration — keys controlling treasuries, bridges, mints, burns, pauses, upgrades, governance, validators, oracles.
4. Introduce crypto-agility — abstract signature verification, versioned address formats, upgradeable wallet modules.
5. Test hybrid modes. Signatures accept iff both pass: Accept ⇔ Verify_classical = 1 and Verify_PQ = 1. Key establishment: K = H(K_classical ‖ K_PQ).
6. Audit PQC implementations by scheme: lattice → side-channel, randomness quality, invalid-input/rejection-sampling; hash-based → domain separation, parameter selection, signature-size budgeting; Falcon → Gaussian-sampler correctness, constant-time, side-channel leakage.
7. Prepare governance/comms — legal, regulatory disclosure, custody agreements, insurance, incident response.

Tool-to-use-case mapping: ML-KEM (+ HQC for diversity) for key establishment; ML-DSA for general signatures; SLH-DSA for trust anchors/emergency keys; Falcon/FN-DSA where calldata is scarce.

Caveats

The page is explicit that its own reassurances are bounded: LWE is not "proven secure" — its worst-case-to-average-case reduction to GapSVP/SIVP is evidence of robustness, not proof, and cryptographic parameters sit in the approximation regime where lattice problems are not believed NP-hard. Grover's 2^(n/2) is a query bound that overstates real cost (barely parallelizes — √P not P; sequential depth prohibitive), so hash sizing is an engineering tradeoff, not a solved problem. LeanSig is early-stage research, not production-ready. Hybrid modes add size, verification cost, and new failure modes.