Why Digital Signatures Needed a Replacement
For three decades, the security of digital signatures has rested on a single mathematical assumption: that recovering a private key from its corresponding public key requires solving the elliptic-curve discrete logarithm problem, a task that takes classical computers longer than the age of the universe. ECDSA and its close relative EdDSA have served blockchain networks, TLS certificates, and software signing pipelines so reliably that most engineers treat them as permanent infrastructure rather than temporary technology.
They are not permanent. Shor's algorithm reduces the elliptic-curve discrete logarithm problem to polynomial time on a sufficiently powerful quantum computer. When fault-tolerant quantum hardware arrives, every ECDSA signature ever made becomes retroactively insecure, and every public key ever exposed on a blockchain becomes an open invitation to theft. The harvest now, decrypt later attack strategy means that adversaries are already collecting this data in anticipation of that moment.
NIST spent eight years running the most rigorous public cryptographic competition in history to find a replacement. In August 2024, it published three final standards. CRYSTALS-Dilithium, formalised as FIPS 204 under the name ML-DSA (Module Lattice Digital Signature Algorithm), is the primary result for digital signatures. Understanding why Dilithium won, how it works, and what it costs in practice is essential for anyone building infrastructure that needs to survive the next decade.
The Module Learning With Errors Problem
Dilithium's security derives from the Module Learning With Errors (MLWE) problem, a structured variant of the Learning With Errors problem that Oded Regev introduced in 2005. To understand MLWE, it helps to start one level down.
The plain LWE problem asks: given a large number of noisy linear equations over a finite field, recover the secret vector that generated them. The "noise" is the key ingredient. Without it, Gaussian elimination solves the system in polynomial time. With small random noise added to each equation, the system becomes hard to solve even for quantum computers, because Shor's algorithm has no traction on the unstructured search that LWE recovery requires.
Module LWE lifts this construction into a module of polynomial rings. Instead of working with vectors of integers, it works with vectors of polynomials in the ring of integers modulo a prime, with coefficients reduced modulo a cyclotomic polynomial. This algebraic structure enables far more efficient arithmetic, because polynomial multiplication in this ring can be computed using the Number Theoretic Transform in O(n log n) time rather than O(n squared). The module structure also allows fine-grained parameter tuning: security level scales with module rank k, giving protocol designers precise control over the security versus performance trade-off.
The best known quantum algorithms for attacking MLWE are variants of the lattice sieving approach, with complexity that scales exponentially in the lattice dimension. No quantum speedup comparable to Shor's has been demonstrated, and the cryptographic community's current consensus, validated through NIST's evaluation period, is that MLWE remains hard even against fault-tolerant quantum adversaries.
How Dilithium Signs and Verifies
Dilithium uses a Fiat-Shamir with Aborts construction, which converts an interactive identification protocol into a non-interactive signature scheme through the random oracle model. The signing algorithm proceeds roughly as follows.
Key generation produces a matrix A drawn uniformly from the polynomial ring, a secret key consisting of short polynomial vectors s1 and s2, and a public key t derived from A times s1 plus s2. The shortness of s1 and s2 is what ties the public key to the secret, without making recovery feasible.
To sign a message, the signer samples a fresh masking vector y with short coefficients, computes a commitment w from A times y, hashes the commitment together with the message to produce a challenge c, and then computes the response z from y plus c times s1. Before outputting the signature, the algorithm checks that z is short enough to not leak information about s1. If the check fails, it aborts and restarts with a fresh y. This rejection sampling step is what the "with Aborts" in the construction name refers to, and it is essential for security: without it, the response would correlate with the secret.
Verification is straightforward: recompute A times z minus c times t, check that the result matches the commitment in the signature, and verify the hash. The entire verify operation involves only public values and runs in microseconds on commodity hardware.
Three Security Levels: Dilithium2, Dilithium3, Dilithium5
NIST standardised Dilithium at three security levels, each targeting a different classical security analogue.
- Dilithium2 (ML-DSA-44) targets NIST security level 2, roughly equivalent to AES-128. Public key: 1,312 bytes. Signature: 2,420 bytes. This is the fastest and smallest variant, appropriate for high-throughput environments where the threat model does not require maximum margin.
- Dilithium3 (ML-DSA-65) targets NIST security level 3, roughly equivalent to AES-192. Public key: 1,952 bytes. Signature: 3,293 bytes. This is the recommended baseline for most new deployments according to NIST guidance, balancing security margin with performance.
- Dilithium5 (ML-DSA-87) targets NIST security level 5, roughly equivalent to AES-256. Public key: 2,592 bytes. Signature: 4,595 bytes. This is the maximum security variant, appropriate for long-lived signatures and the highest-assurance use cases.
For context against classical algorithms: an ECDSA P-256 public key is 64 bytes and a signature is 64 bytes. A Dilithium3 public key is roughly 30 times larger, and a signature is roughly 50 times larger. This size increase is real and has implications for network bandwidth and storage, but it is the unavoidable cost of mathematical hardness that does not collapse under quantum attack. Importantly, key generation and signing performance in software is competitive with ECDSA on modern CPUs, often faster once AVX2 vectorisation is applied to the NTT arithmetic.
Performance Benchmarks
Benchmarks from the NIST evaluation period and subsequent independent measurements on x86-64 hardware with AVX2 acceleration show Dilithium performing well against its alternatives.
On a modern server CPU, Dilithium3 key generation runs in approximately 60 microseconds, signing in approximately 90 microseconds, and verification in approximately 70 microseconds. These figures are broadly comparable to ECDSA P-256, which runs key generation in roughly 50 microseconds and signing in roughly 70 microseconds in optimised implementations. The difference is small enough that signature overhead is rarely the bottleneck in production systems.
Memory requirements are modest. The entire signing and verification operation fits within L1 cache on current processors, which means Dilithium scales well under parallelism. A validator node processing thousands of transactions per second can verify Dilithium signatures without signature verification becoming the throughput constraint.
The main practical cost is bandwidth. At 3,293 bytes per signature for Dilithium3, a blockchain processing one million transactions per day carries roughly 3.3 GB of daily signature data, compared to roughly 64 MB for the same load under ECDSA. This is manageable but not negligible, and it is one reason why blockchain architectures deploying post-quantum signatures benefit from compression-aware storage and efficient serialisation formats.
Why Dilithium Won Over FALCON
FALCON, the other NIST-selected signature scheme based on NTRU lattices, produces significantly smaller signatures than Dilithium, roughly 666 bytes for FALCON-512 and 1,280 bytes for FALCON-1024, with public keys of 897 and 1,793 bytes respectively. On pure size metrics, FALCON is the more appealing choice for bandwidth-constrained applications.
NIST selected both, but recommended Dilithium as the primary scheme for most use cases. The reasons are practical rather than theoretical.
FALCON's signing algorithm requires sampling from a discrete Gaussian distribution over a specific algebraic structure, using a procedure called fast Fourier sampling over NTRU lattices. This operation is subtle to implement correctly. Multiple independent analyses during the NIST competition identified side-channel vulnerabilities in naive implementations, where timing variations during the Gaussian sampling step leaked information about the private key. Constant-time implementation of FALCON signing requires careful engineering, and even hardware-accelerated constant-time implementations require domain expertise to audit.
Dilithium's rejection sampling approach is substantially simpler to implement without side channels. The operations involved, polynomial arithmetic and hash function evaluation, have well-understood constant-time implementations, and the abort-and-retry structure means the signing time varies only in expected iteration count, not in a way that directly correlates with key material.
For a system processing financial transactions where implementation security matters as much as algorithmic security, Dilithium's auditability advantage is significant. FALCON remains the right choice for applications where signature size is the dominant constraint and implementation teams have the expertise to deploy it safely. For general-purpose deployment across diverse validator infrastructure, Dilithium is the sounder choice.
How QuanChain Deploys Dilithium Across TADEQS
QuanChain's TADEQS (Threat-Adaptive Dynamic Encryption and Quantum Security) architecture structures cryptographic protection into 20 security tiers, each calibrated to a specific threat model defined by the Quantum Oracle's real-time assessment of quantum computing capability.
At the lower tiers, covering threat environments where quantum attack remains economically infeasible, QuanChain operates with Dilithium2 signatures to maximise transaction throughput across its three-channel architecture. This keeps signature overhead low for the high-frequency payment workloads on Channel 1, which processes over 200,000 transactions per second.
As the Oracle's LQCp/h metric crosses escalating thresholds, TADEQS automatically migrates wallet activity to higher Dilithium security levels, reaching Dilithium5 at the upper tiers where the quantum threat is assessed as proximate. Critically, this migration happens without user action. The SpendAndRotate mechanism, which atomically rotates key material at every spend event, means that every transaction naturally incorporates the current tier's security parameters. No user needs to regenerate a wallet or resubmit credentials when the network upgrades its cryptographic posture.
This design has a second benefit beyond security: it means QuanChain's on-chain signature data never contains exposed public keys from previous security levels. Unlike vulnerable blockchains that permanently record ECDSA public keys on-chain, QuanChain's public key exposure window is exactly one transaction, after which the corresponding key material is retired. Even if an adversary harvests that signature data, the key it targets has already been rotated away.
The upper TADEQS tiers also combine Dilithium5 with SPHINCS+-256f, a hash-based signature scheme whose security relies only on the collision resistance of the underlying hash function rather than any lattice assumption. Using two independent post-quantum primitives in combination means a breakthrough against lattice problems, which remain an active area of mathematical research, does not by itself compromise the network's top-tier security guarantees.
For a full picture of how the Oracle feeds threat signals into TADEQS tier selection, the Quantum Threat Calculator provides a live view of where current hardware sits on the escalation curve and what that means for signature security today.
The Broader Landscape
Dilithium's standardisation is part of a broader transition that every blockchain will eventually have to make. The migration problem for existing blockchains is significantly harder than for new systems, because those networks carry years of exposed public keys that cannot be un-exposed. Q-Day, the point at which a quantum computer can break ECDSA at scale, is not a fixed date on the calendar, but the trajectory of hardware improvement gives it a probability distribution that is shifting toward the near term with each passing year.
Networks that have not begun the transition to schemes like ML-DSA face a progressively narrowing window. The key insight from Dilithium's design, and from the NIST evaluation process that produced it, is that post-quantum security does not require sacrificing performance or operational simplicity. The signing and verification times are competitive. The implementation risks are manageable with proper engineering. The mathematical foundations have survived eight years of adversarial scrutiny from the global cryptographic research community.
The remaining cost, larger keys and signatures, is one that well-designed systems can absorb without architectural disruption. For systems being built today, there is no credible justification for choosing ECDSA over ML-DSA. The question is not whether to make the transition, but whether the infrastructure beneath your application has already made it. For a comparison of where current networks stand, the quantum-resistant blockchain overview and the properties that define genuine quantum resistance provide a useful baseline for evaluation.
ML-DSA is not a theoretical placeholder waiting for quantum computers to arrive. It is a production-ready standard with competitive performance, a clean implementation profile, and eight years of public cryptanalytic scrutiny behind it. The only remaining question is how quickly the industry deploys it.
