[MLDSA] Lax decoding of expanded private keys

[romen]

Running wycheproof tests against the bc-rust mldsa implementation I noticed failures in

https://github.com/randombit/wycheproof-rs/blob/master/src/data/mldsa_65_sign_noseed_test.json#L667-L706

(and the analogous ones for MLDSA44/87).

These are about rejecting private keys where the encoded s1/s2 values are out of bounds compared to the legit output of the standardized encode algorithm.

Alg.25 of FIPS 204 has comments about this:

▷ this may lie outside [−𝜂, 𝜂] if input is malformed

I believe the Alg. 25 skDecode function is written without any failure case due to this previous comment:

Note that there exist malformed inputs that can cause skDecode to return values that are not in the correct range. Hence, skDecode should only be run on inputs that come from trusted sources.

But in reality most implementation do try to consider even the encoded secret key material to be input that needs validation: even trusted inputs can be subject to human errors and bit-flips due to cosmic rays :)

[Quant-TheodoreFelix]

I got curious about this one and spent some time tracing it through the code on current main(aefbb6a). Sharing what I found in case it’s useful, along with a couple of ideas for a fix.

It looks like the expanded-key decoder reconstructs s1/s2 coefficients without checking that they fall back inside [-eta, eta], so a malformed or corrupted secret key gets accepted rather than rejected.

bit_unpack_eta(mirrored in mldsa_lowmemory) reads a c-bit field with c = bitlen(2*eta) and computes the coefficient as eta - x. That field is a bit wider than the valid range, so out-of-range values are representable:

• eta = 2 (ML-DSA-44 / ML-DSA-87): 3-bit x in [0, 7] -> coeff in [-5, 2], valid is [-2, 2]. So x in {5, 6, 7} slips through.
• eta = 4 (ML-DSA-65): 4-bit x in [0, 15] -> coeff in [-11, 4], valid is [-4, 4]. So x in [9, 15] slips through.

The caller sk_decode (mldsa_keys.rs:L630 for s1, :L650 for s2) copies the unpacked polynomial in as-is, so there’s no place that catches these.

One thing I wanted to flag so it doesn’t cost anyone time: the t0 path (bit_unpack_t0) looks fine to me and probably doesn’t need a check. Its 13-bit field maps exactly onto the valid (-2^(d-1), 2^(d-1)] range, so no out-of-range value is even representable there.

FIPS 204 Algorithm 25 (skDecode) actually calls this out itself, noting coefficients “may lie outside [-eta, eta] if input is malformed” and skipping the check on a trusted-input assumption. The ML-KEM side of this same repo already does the analogous validation, though, pk_decode (crypto/mlkem/src/mlkem_keys.rs) rejects coefficients >= q, so adding an s1/s2 range check would just bring the two decoders in line with each other.