ML-DSA and module-lattice signature obligations
Research context
postgraduate concept · conditional · As of 2026-10-10
FIPS 204 ML-DSA standardizes the Dilithium-derived module-lattice signature design, with ML-DSA-44/65/87 at security categories 2/3/5.
Key knowledge
FIPS 204 ML-DSA standardizes the Dilithium-derived module-lattice signature design, with ML-DSA-44/65/87 at security categories 2/3/5. Security analysis uses selected module-lattice hardness problems rather than a theorem that every lattice problem is hard. Default hedged and optional deterministic signing, bounded context strings and prehash mode have different interfaces and randomness obligations. Pure ML-DSA and HashML-DSA must not be silently treated as identical message encodings.
Conditions and scope
- Record exact parameter set, signature variant, context/domain encoding and implementation randomness/fault assumptions.
- A category compares resource estimates against stated reference primitives; it is not unconditional security.
Sources · 1
References
Sources retain their recorded scope. A source link alone does not establish verification of every statement.
Evidence and review
Author checked this English statement, displayed equation where present and stated hypotheses against these source locations: §§3–5 ML-DSA/SIS-LWE assumptions, security categories, Table 2, hedged/deterministic and prehash/context distinctions. The check is bounded to the recorded claims; no complete proof reconstruction, software proof replay or universal literature completeness is claimed.
2026-10-10 · Author source-body/statement/equation/domain check, with graph associations scoped individually. Separate independent content/source/inventory review is required before branch closure.
Entry details
Permanent link to this entry ↗- Record identity
- research-info-module-lattice-signatures
- Revision
- research.1
- Structured reference record
- Postgraduate & research reference