The Three Finalized NIST PQC Standards
In August 2024, NIST finalized its first three post-quantum cryptography standards after an eight-year evaluation process. These standards replace classical public-key cryptography in applications where long-term security against quantum adversaries is required:
- FIPS 203 (ML-KEM): Module-Lattice Key Encapsulation Mechanism, based on CRYSTALS-Kyber. Used for key exchange and key encapsulation.
- FIPS 204 (ML-DSA): Module-Lattice Digital Signature Algorithm, based on CRYSTALS-Dilithium. The primary post-quantum replacement for ECDSA.
- FIPS 205 (SLH-DSA): Stateless Hash-Based Digital Signature Algorithm, based on SPHINCS+. A conservative backup based on hash function security rather than lattice assumptions.
A fourth standard, FIPS 206 (FN-DSA, based on FALCON), was finalized in August 2024 as well. This guide focuses on the three listed above as the most practically relevant for blockchain implementation.
FIPS 203: ML-KEM for Key Exchange
ML-KEM replaces Diffie-Hellman key exchange and RSA key encapsulation. In a blockchain context, it is used when two parties need to establish a shared secret for encrypted communication — relevant for validator communication, private transaction channels, and off-chain messaging.
Parameters
| Security Level | Parameter Set | Public Key Size | Ciphertext Size | Equivalent Classical Security |
|---|---|---|---|---|
| Level 1 | ML-KEM-512 | 800 bytes | 768 bytes | AES-128 |
| Level 3 | ML-KEM-768 | 1,184 bytes | 1,088 bytes | AES-192 |
| Level 5 | ML-KEM-1024 | 1,568 bytes | 1,568 bytes | AES-256 |
For most blockchain applications, ML-KEM-768 provides an appropriate security margin. The key and ciphertext sizes are larger than classical DH but well within acceptable bounds for authenticated encrypted channels.
FIPS 204: ML-DSA for Transaction Signing
ML-DSA is the primary post-quantum replacement for ECDSA. It uses Module Learning With Errors (MLWE) hardness, a lattice problem that is not known to be solvable efficiently by quantum computers.
Parameters
| Security Level | Parameter Set | Public Key | Private Key | Signature Size | Equivalent Classical Security |
|---|---|---|---|---|---|
| Level 2 | ML-DSA-44 | 1,312 bytes | 2,528 bytes | 2,420 bytes | ~AES-128 |
| Level 3 | ML-DSA-65 | 1,952 bytes | 4,000 bytes | 3,309 bytes | ~AES-192 |
| Level 5 | ML-DSA-87 | 2,592 bytes | 4,864 bytes | 4,595 bytes | ~AES-256 |
The signature size increase relative to ECDSA (64 bytes) is the primary engineering challenge for blockchain adoption. An ML-DSA-44 signature is 38 times larger than an ECDSA signature. This has direct implications for block size, transaction throughput, and storage requirements.
Implementation Pattern for Transaction Signing
Replacing ECDSA with ML-DSA in a blockchain transaction involves three changes:
- Key generation: Replace secp256k1 keypair generation with ML-DSA key generation from a seed. The seed can be derived from a BIP32-compatible HD wallet derivation path if the derivation function is updated to output ML-DSA seeds.
- Signing: Replace ECDSA sign with ML-DSA sign. The signing function takes the private key and message hash as input, returns a 2,420-4,595 byte signature depending on the parameter set chosen.
- Verification: Replace ECDSA verify with ML-DSA verify. The verification function takes the public key, message hash, and signature. Verification is faster than signing, which is favorable for blockchain validation nodes that verify many more signatures than they produce.
Pseudocode for the signing migration:
// Classical ECDSA
const keypair = secp256k1.generateKeypair(seed)
const sig = secp256k1.sign(txHash, keypair.privateKey)
const valid = secp256k1.verify(txHash, sig, keypair.publicKey)
// Post-quantum ML-DSA
const keypair = mlDSA44.generateKeypair(seed)
const sig = mlDSA44.sign(txHash, keypair.privateKey) // returns 2,420 bytes
const valid = mlDSA44.verify(txHash, sig, keypair.publicKey)
FIPS 205: SLH-DSA as a Conservative Backup
SLH-DSA (SPHINCS+) is a hash-based signature scheme. Its security relies entirely on the collision resistance of a hash function — a much older and more studied assumption than lattice hardness. This makes SLH-DSA more conservative: even if lattice-based cryptography were somehow broken, SLH-DSA would remain secure as long as the underlying hash function (SHA-256 or SHAKE) is secure.
Parameters
| Variant | Parameter Set | Public Key | Signature Size | Notes |
|---|---|---|---|---|
| Fast (f) | SLH-DSA-SHAKE-128f | 32 bytes | 17,088 bytes | Faster signing, larger sig |
| Small (s) | SLH-DSA-SHAKE-128s | 32 bytes | 7,856 bytes | Smaller sig, slower signing |
| Fast (f) | SLH-DSA-SHAKE-256f | 64 bytes | 49,856 bytes | Highest security, largest sig |
SLH-DSA's signature sizes are significantly larger than ML-DSA, making it impractical as a primary blockchain signature scheme. Its role is as a fallback or backup signature that provides a second layer of security independent of lattice assumptions. High-security contexts such as root certificate authorities or governance keys that are used infrequently may choose SLH-DSA for its conservative security properties.
Hybrid Signatures During Transition
A common implementation pattern during migration is to use hybrid signatures: a transaction carries both an ECDSA signature (for backward compatibility with existing validators) and an ML-DSA signature (for forward quantum resistance). Both are required to be valid.
This approach provides immediate quantum resistance while maintaining compatibility with validators that have not yet upgraded. The cost is doubled signature size, which compounds the throughput challenge. Hybrid signatures should be treated as a transitional mechanism rather than a long-term architecture.
Block Size and Throughput Implications
A blockchain that replaces ECDSA with ML-DSA-44 will see transaction sizes increase by approximately 2,356 bytes per signature (2,420 - 64 = 2,356, plus public key size difference). For a chain processing 1,000 transactions per second, this is an additional 2.35 GB of signature data per 1,000 seconds.
Managing this overhead requires one or more of:
- Increased block sizes to maintain transaction throughput
- Signature aggregation schemes that batch multiple signatures into a smaller combined proof
- Multi-channel architectures that separate high-volume payments (needing only lightweight signatures) from complex contracts requiring full verification
- Data compression applied to signature data across a block
QuanChain's three-channel architecture and 70% data compression were designed specifically to absorb this overhead while maintaining competitive throughput.
