Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
There's a bug in the usehint function where it adds 1 instead of subtracting 1 when the decomposed low bits r0 equal exactly zero. FIPS 204 Algorithm 40 is pretty clear that r0 0 means strictly positive, but the current code treats zero as positive. This causes valid signatures to potentially fail verification when this edge case gets hit. Details The issue is in ml-dsa/src/hint.rs in the usehint function. Here's what FIPS 204 Algorithm 40 says: Line 3 uses r0 0 (strictly greater than zero), and line 4 uses r0 <= 0 (less than or equal, which includes zero). So when r0 = 0, the spec says to subtract 1. But the current implementation does this: The problem is r0.0 <= gamma2 includes zero. When r0 = 0, this condition is true (since 0 <= gamma2), so it adds 1. But according to the spec, r0 = 0 should fall into the r0 <= 0 case and subtract 1 instead. The result is +1 when it should be -1, which is an off by two error mod m. PoC Take MLDSA 44 where γ2 = 95,232 and m = 44. If…
Recommended action: Upgrade to 0.1.0-rc.5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 (<= instead of <), allowing duplicate indices. Note: This is a regression bug. The original implementation was correct, but commit b01c3b7 ("Make ML-DSA signature decoding follow the spec (#895)", fixing issue #894) inadvertently changed the strict < comparison to <=, introducing the vulnerability. Vulnerability Details Root Cause The vulnerability is located in the monotonic helper function in ml-dsa/src/hint.rs: The comparison operator <= allows equal consecutive values, meaning duplicate hint indices are not…
Recommended action: Upgrade to 0.1.0-rc.4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A timing side-channel was discovered in the Decompose algorithm which is used during ML-DSA signing to generate hints for the signature. Details The analysis was performed using a constant-time analyzer that examines compiled assembly code for instructions with data-dependent timing behavior. The analyzer flags: - UDIV/SDIV instructions: Hardware division instructions have early termination optimizations where execution time depends on operand values. The decompose function used a hardware division instruction to compute r1.0 / TwoGamma2::U32. This function is called during signing through highbits() and lowbits(), which process values derived from secret key components: - (&w - &cs2).lowbits() where cs2 is derived from secret key component s2 - Hint::new() calls highbits() on values derived from secret key component t0 Original Code: PoC I do not have an exploit written for this, currently. Impact The dividend (r1.0) is derived from secret key material. An attacker with…
Recommended action: Upgrade to 0.1.0-rc.3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.