GHSA-5x2r-hc65-25f9 ML-DSA Signature Verification Accepts Signatures with Repeated Hint Indices

• crates.io ml-dsa: >= 0.0.4, < 0.1.0-rc.4 → fixed in 0.1.0-rc.4

Affected Crate: `ml-dsa` Affected Versions: v0.1.0-rc.2 (and commits since `b01c3b7`) Severity: Medium Reporter: Oren Yomtov (Fireblocks) Summary The ML-DSA signature verification implementation in the RustCrypto `ml-dsa` crate incorrectly accepts signatures with repeated (duplicate) hint indices. According to the ML-DSA specification (FIPS 204 / RFC 9881), hint indices within each polynomial must be strictly increasing. The current implementation uses a non-strict monotonic check (` bool { a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] bool { a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] bool { a.iter().enumerate().all(|(i, x)| i == 0 || a[i - 1] < *x) } ``` Design Intent: ML-DSA is NOT Intended to Allow Malleability While some cryptographic libraries intentionally permit signature malleability for compatibility or performance reasons, ML-DSA is explicitly designed to prevent it: 1. FIPS 204 Specification: ML-DSA is designed to be strongly unforgeable under chosen message attacks (SUF-CMA). This security property explicitly prevents signature malleability. 2. NIST PQC Forum Discussion: In February 2024, there was a discussion on the NIST PQC forum about potential malleability in ML-DSA's hint unpacking. The consensus was that ML-DSA is intended to be SUF-CMA, meaning any malleability issues should be considered bugs and fixed. 3. No Documentation of Intentional Malleability: There is no documentation in the RustCrypto `ml-dsa` crate, FIPS 204, or RFC 9881 suggesting that signature malleability is an acceptable or intentional property. 4. Regression Bug: The fact that the original implementation had strict ordering (`<`) and this was changed to non-strict (`<=`) in a "fix" commit suggests this was an unintentional regression, not a design decision.