The Longest Standardization Process in Cryptographic History
On August 13, 2024, the National Institute of Standards and Technology published FIPS 203, FIPS 204, and FIPS 205 as final federal standards. A fourth standard, FIPS 206, followed in the same release batch. The publication marked the conclusion of a competition that NIST launched in December 2016 and that ran through multiple grueling evaluation rounds over nearly eight years. No modern cryptographic standardization effort has been scrutinized as heavily, lasted as long, or had more publicly visible casualties along the way.
The resulting four standards are not theoretical research documents. They are operational specifications that governments, technology vendors, and critical infrastructure operators are expected to implement. NIST has explicitly tied these standards to a migration timeline: the agency recommends that organizations begin transitioning away from RSA and elliptic-curve cryptography toward the new algorithms now, and has indicated that classical public-key algorithms should be phased out of federal use by 2035. Understanding what post-quantum cryptography is and why it matters is the necessary starting point, but the August 2024 finalization moves the conversation from theory to implementation.
The Four Standards: What They Are and What They Do
FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)
ML-KEM is a key encapsulation mechanism, not a key exchange protocol or an encryption scheme in the traditional sense. Its function is specific: it allows one party to encapsulate a shared secret using the other party's public key, and the recipient decapsulates it using their private key. The resulting shared secret can then be used to derive a symmetric key for encrypted communication.
ML-KEM is derived from CRYSTALS-Kyber, one of the most-analyzed candidates in the NIST competition. Its security rests on the hardness of the Module Learning With Errors problem, a structured variant of LWE that quantum computers cannot solve efficiently with any known algorithm. ML-KEM is defined at three security levels: ML-KEM-512 (roughly equivalent to AES-128 classical security), ML-KEM-768 (AES-192 equivalent), and ML-KEM-1024 (AES-256 equivalent). Most deployments targeting long-term security are expected to use ML-KEM-768 or ML-KEM-1024.
Key sizes in ML-KEM are substantially larger than their elliptic-curve equivalents. An ML-KEM-768 public key is 1,184 bytes. For comparison, a Curve25519 public key is 32 bytes. This difference has real implications for protocols where key size adds to bandwidth or storage overhead, including blockchain transaction formats.
FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)
ML-DSA is the primary digital signature standard to emerge from the competition. It derives from CRYSTALS-Dilithium and, like ML-KEM, uses the Module Learning With Errors problem as its security foundation. ML-DSA produces digital signatures that can be verified without exposing the private signing key, and its security against quantum adversaries running Shor's algorithm is qualitatively different from ECDSA: there is no known quantum algorithm that solves the underlying lattice problem efficiently.
ML-DSA operates at three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, corresponding to increasing security levels. At the ML-DSA-65 level, public keys are 1,952 bytes and signatures are 3,293 bytes. Both figures dwarf their ECDSA equivalents, where a compressed public key is 33 bytes and a signature is 64 bytes. The size expansion is the central engineering challenge for systems that currently assume small, efficient signatures.
For blockchain projects specifically, this size difference is not academic. Every transaction that requires a signature carries more data on-chain. Block space becomes more constrained at the same transaction throughput. Existing block size limits would need adjustment to accommodate the same number of signed transactions per block. What a quantum-resistant blockchain requires at the infrastructure level goes well beyond swapping one algorithm for another.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
SLH-DSA derives from SPHINCS+ and represents a fundamentally different security basis than the lattice-based standards. Its security depends entirely on the properties of cryptographic hash functions, not on lattice problems. This matters because hash functions and lattice problems are independent assumptions: an attack that breaks one does not break the other. SLH-DSA functions as a conservative fallback whose security does not depend on the novelty of lattice cryptography being sustained.
The tradeoff is performance. SLH-DSA signatures are large, ranging from around 7,856 bytes to 49,856 bytes depending on the parameter set chosen, and signing is computationally slower than ML-DSA. NIST positioned SLH-DSA as a secondary standard, appropriate for contexts where a diversity of security assumptions is valuable or where the lattice-based alternatives cannot be used. For high-throughput applications, ML-DSA will typically be preferred.
FIPS 206: FN-DSA (FFT over NTRU Lattice Digital Signature Algorithm)
FN-DSA derives from FALCON and is based on NTRU lattices rather than the Module-LWE structure underlying ML-DSA. Its defining characteristic is compact signatures: FN-DSA-512 produces signatures of around 666 bytes, substantially smaller than ML-DSA at equivalent security levels. This compactness makes FN-DSA attractive for constrained environments and bandwidth-sensitive protocols.
The tradeoff is implementation complexity. FN-DSA requires floating-point arithmetic during key generation and signing, which introduces potential side-channel vulnerabilities if not implemented carefully. NIST's own guidance notes that FN-DSA is harder to implement securely than ML-DSA and recommends it primarily for use cases where signature size is a binding constraint. For most software deployments, ML-DSA is the simpler and safer primary choice.
Which Candidates Were Broken and Why It Matters
The eight-year evaluation period was not a formality. Several candidates that appeared promising were broken outright, and understanding those breaks clarifies both the robustness of the final standards and the difficulty of the cryptographic engineering involved.
The most significant break during the evaluation period came in July 2022, when researchers published an attack against SIKE (Supersingular Isogeny Key Encapsulation), a finalist that had advanced to the fourth round. SIKE was based on isogeny-based cryptography, a different mathematical foundation than any of the selected algorithms. The attack was classical, not quantum, and it broke SIKE on a standard laptop in hours using only 62 megabytes of memory. A candidate that had survived multiple rounds of scrutiny by hundreds of researchers turned out to have a fundamental structural weakness that had gone undetected for years.
RAINBOW, a signature scheme based on multivariate polynomials, was broken in a separate attack in 2022. The attack was also classical, not quantum, and it recovered the signing key for the highest security parameter set in about 53 hours on a single laptop. RAINBOW was a third-round finalist at the time of the attack.
These breaks matter for a reason beyond the individual candidates. They demonstrate that the selection process worked. Algorithms were not promoted to final standards because they survived scrutiny in a closed review; they were subjected to open, adversarial analysis by the global cryptographic research community, and the ones that failed were eliminated before standardization. The four algorithms that reached final FIPS status have been tested more aggressively than any cryptographic standards in history. That does not guarantee they are unbreakable, but it substantially raises the confidence bar.
The breaks also illustrate the risk of deploying algorithms before they have reached standardization. Any blockchain or infrastructure project that implemented SIKE or RAINBOW for early post-quantum security during the evaluation period would need to migrate again after the breaks. This is a concrete argument for using NIST-standardized algorithms rather than pre-standard candidates, even when the latter appear technically sound.
Migration Timelines: What NIST Actually Said
NIST's guidance on migration timelines is more specific than most coverage of the August 2024 announcement reflected. The agency's formal position is that organizations should begin planning and executing their migration to the new standards immediately, particularly for any system that handles data with a confidentiality requirement extending past 2030. The harvest now, decrypt later threat model is explicitly cited as the driver: adversaries who can collect encrypted traffic today and decrypt it once quantum hardware matures create a threat that begins now, not when quantum computers actually arrive.
For digital signatures, the urgency is different but still real. Signature schemes are primarily threatened by real-time quantum attacks rather than harvest-and-decrypt operations, so the migration timeline for signatures is tied more directly to hardware progress. NIST's formal deprecation schedule calls for disallowing classical key agreement and signature schemes in federal systems by 2035, with a strong recommendation to begin transition well before that date to allow for testing, validation, and ecosystem adoption.
The 2035 horizon sounds distant but is not. Enterprise software has long update cycles. Critical infrastructure often runs on systems that cannot be patched easily. Blockchain networks face the additional challenge that protocol changes require community consensus and coordinated upgrades across thousands of independent nodes. The blockchain quantum migration problem is already apparent to anyone who has observed how slowly existing networks respond to protocol-level changes, even when the changes are uncontroversial.
What the Standards Mean for Blockchain Projects
The August 2024 standards crystallize the algorithm choices that serious quantum-resistant blockchain infrastructure should be built on. Before finalization, a project building with post-quantum cryptography had to make a judgment call on which candidates were likely to survive. After finalization, that uncertainty is substantially reduced for the four standardized algorithms.
The practical implications for blockchain design fall into three categories.
First, transaction signature verification. Every transaction on a quantum-resistant blockchain needs to be signed with a post-quantum algorithm. ML-DSA is the natural primary choice for most implementations given its relative implementation simplicity and well-characterized security properties. FN-DSA is viable for systems where signature compactness is critical. The size difference compared to ECDSA is real and requires either larger blocks, lower throughput, or more efficient compression approaches to accommodate the same transaction volume.
Second, key management architecture. The NIST standards specify the algorithms but not the key management policies around them. A blockchain can implement ML-DSA signing correctly and still expose users to quantum risk if public keys are placed on-chain in recoverable form. The attack surface that Shor's algorithm exploits is the availability of public key material, not simply the signing algorithm used. TADEQS architecture addresses this by ensuring that no signing public key is ever placed in a recoverable on-chain record, eliminating the harvest surface regardless of future quantum hardware capability.
Third, key encapsulation and channel security. Blockchain nodes communicate with each other continuously. If that communication uses TLS or similar protocols built on classical key exchange, an adversary harvesting node traffic today can decrypt it later. Replacing classical key exchange with ML-KEM in node-to-node communication is part of a complete post-quantum posture, not just an optional upgrade. The Quantum Oracle framework for monitoring threat-level changes makes little sense without the underlying communication layer being post-quantum protected as well.
It is also worth noting what the NIST standards do not cover: consensus mechanisms, validator incentive structures, and cross-chain security anchoring. A blockchain can implement all four FIPS standards and still have a consensus layer that assumes classical cryptographic hardness in ways that are not immediately obvious. Proof of Coherence was designed with these assumptions explicit from the start, rather than treating them as implementation details to be addressed later.
The Gap Between Standardization and Deployment
The cryptographic community has produced post-quantum standards. The engineering community now has to deploy them. That gap is where most of the actual work lies, and it is a gap that the blockchain industry is particularly poorly positioned to close quickly.
Existing blockchains cannot simply swap their signature schemes. Every wallet, every transaction format, every contract that validates signatures on-chain, and every tool in the developer ecosystem assumes specific key and signature sizes. A migration from ECDSA to ML-DSA on an existing production network requires not just a protocol upgrade but a coordinated wallet migration, a transition period where both old and new formats are valid, and a mechanism for retiring legacy keys that may hold significant value. Which cryptocurrencies are most vulnerable to quantum attacks depends partly on how quickly their communities can execute this kind of coordinated upgrade, and historical evidence from existing networks is not encouraging.
New blockchain infrastructure built from scratch after the August 2024 standards has none of these legacy constraints. It can adopt ML-DSA, ML-KEM, and the supporting key management architecture as native primitives rather than retrofitted additions. Use the Quantum Threat Calculator to model how hardware timelines interact with your specific exposure profile, and consider the properties a genuinely quantum-resistant blockchain requires before assuming that any single algorithm upgrade is sufficient.
The NIST finalization in August 2024 was not the end of the post-quantum transition. It was the moment when the transition became obligatory rather than optional for anyone building systems that need to remain secure beyond the current decade.
FIPS 203, 204, 205, and 206 give the industry a stable foundation to build on. What happens next depends on how quickly that foundation gets incorporated into real infrastructure, and how honestly the engineering challenges of doing so, especially in distributed systems with millions of existing users, are confronted. The standards exist. The question is whether deployment keeps pace with the hardware progress that made them necessary.
