The mldsa_verify_test macro previously hardcoded MlDsa44 for decoding both verifying keys and signatures. Due to public key length mismatches, this caused tests for ML-DSA-65 and ML-DSA-87 to fail type conversion and be silently skipped.
Using $params ensures test vectors for all parameter sets are properly decoded and verified.
Implements these traits sourced from the `crypto-common` crate.
Also implements the `Generate` trait for key generation, replacing the
previous `KeyGen` trait, which this commit deprecates in favor of using
`KeyInit` and `Generate`.
This also adds a `getrandom` feature that forwards through to
`crypto-common`, making methods available on the `Generate` trait when
enabled.
This reworks the API to make KeyGen::from_seed return a
`SeededSigningKey` instead of a `KeyPair`.
The `SeededSigningKey` effectively replaces the `KeyPair`, and instead
of eagerly generating the VerifyingKey (implementing
`signature::KeypairRef`), it implements `signature::Keypair` and makes
the verifying key when requested.
This reduces the depth of the stack when calling from_seed and reduces
the size of the stack by 207kb using ML-DSA-87 in debug/tests builds
(the heaviest consumers).
This is an API break.
Corrects the check for monotonically increasing hint indexes reported as
GHSA-5x2r-hc65-25f9 and reproduced in #1176.
It seems the logic for checking the hint "cuts" (`y[omega + i]`) needs
to remain the same, however.
With this change, we pass the full set of Wycheproof verification test
vectors (i.e. it seems to have fixed the other failure we were
experiencing as well)
Replaces ad hoc randomized testing with proptest, which can
automatically report seeds to reproduce failures experienced in CI, and
can automatically track and test previous regressions.
Adds Wycheproof verification tests for ML-DSA-44/65/87.
On ML-DSA-44, this reproduced an issue previously reported as
GHSA-5x2r-hc65-25f9 by @orenyomtov:
> Test #18: signature with a repeated hint (Invalid)
Likewise, on ML-DSA-44 only we are also failing this case:
> Test #68: public key with t1 component set to zero (Valid)
I have added an exceptions for those two for now, and all the other
tests pass.
I opened #1183 as a tracking issue for these verification failures.
Uses a similar strategy to `rsa`, cloning the Wycheproof test vectors as
a submodule and parsing the JSON files directly (I tried to use
`wycheproof2blb` and it seems really out of date).
Adds the following as an initial integration:
- `mldsa_44_sign_seed_test`
- `mldsa_65_sign_seed_test`
- `mldsa_87_sign_seed_test`
Renames `EncodedSigningKey` to `ExpandedSigningKey` to contrast it with
seeds, the preferred API. Also renames the `decode` and `encode`
functions to `from_expanded` and `to_expanded`, similar to the changes
made to `ml-kem`'s `DecapsulationKey` in RustCrypto/KEMs#163,
which also deprecated these APIs.
We don't properly implement validation of such keys which can lead to
panics in the event they were improperly or maliciously generated
(#1133), a problem avoided by using seeds. For now, this merely
documents the panic condition.
Most implementers have opted not to provide support for this key format
due to these problems (it's also actually more expensive to validate an
expanded key than it is to use a seed), and also where seeds are the
same size regardless of security level, the expanded keys vary in size.
Lukas Zobernig