Digital Signature
ML-DSA
Module-Lattice-based Digital Signature Algorithm · FIPS 204
FIPS-finalisedlattice-based3 parameter setsQNSP tier: default+provider: nobleprovider: liboqsalso called: Dilithium, CRYSTALS-Dilithium, Module-LWE Signature
NIST's primary post-quantum digital signature standard, finalised August 2024 as FIPS 204. ML-DSA powers JWT signing, audit-log integrity, code-signing, and authn token issuance across QNSP.
Mechanism
How it works
ML-DSA is built on the hardness of the Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS) problems. Signatures are generated via the Fiat-Shamir transform applied to an identification protocol over polynomial rings. FIPS 204 Algorithm 1 specifies ML-DSA.KeyGen(ξ) where ξ is a 32-byte random seed, internally calling ML-DSA.KeyGen_internal(ξ). Parameter sets ML-DSA-44 / 65 / 87 target NIST security levels 2 / 3 / 5.
Parameter Sets
3 variants shipped
Each variant trades security category against key, ciphertext, or signature size. QNSP exposes all variants via the @cuilabs/liboqs-native binding; tenant crypto-policy determines which are allowed.
| Variant | NIST Level | Public Key | Secret Key | Signature | Note |
|---|---|---|---|---|---|
| ML-DSA-44 | L2 | 1,312 B | 2,560 B | 2,420 B | JWT signing default. Smallest signature size of the FIPS-finalised signatures. |
| ML-DSA-65 | L3 | 1,952 B | 4,032 B | 3,309 B | Strict policy tier default. Recommended for high-security JWT and audit signing. |
| ML-DSA-87 | L5 | 2,592 B | 4,896 B | 4,627 B | Maximum + Government default. Required for `government` tier. |
NIST ACVP
Conformance evidence
QNSP runs the official NIST ACVP test vectors against every shipped algorithm. Live evidence + SHA-3-256 tamper digest at /verify/conformance.
@noble/post-quantum
passingPure-JavaScript reference; cross-verification secondary on Maximum + Government tiers.
@cuilabs/liboqs-native
deferredNative-C primary production engine. Runs across every QNSP backend service.
noble passes all 75 ML-DSA keyGen ACVP tests. liboqs keyGen tests deferred because liboqs C library 0.15.0 does not yet expose OQS_SIG_keypair_derand. Sign / verify operations run against test vectors that provide the keypair, so signature correctness is independently exercised at runtime by the cross-verification service on Maximum and Government policy tiers.
Use Cases
When to use it
- JWT signing (auth-service default)
- Audit-log Merkle root signing (audit-service)
- Inter-service SPIFFE SVID signing
- Code-signing artefacts
- Compliance evidence-pack signing
Trade-offs
What you give up, what you get
- Larger signatures than Falcon but faster signing and simpler implementation
- Constant-time reference implementation (side-channel resistant)
- Same Module-LWE security assumption as ML-KEM — assumption-economy across families
References