The changes in #1360 were breaking, so this release bumps the minor
version.
It might be possible to get some additional breaking changes in as well,
if we can land RustCrypto/crypto-bigint#1266.
This renames the old `SigningKey::generate` to
`try_generate_from_rng_with_components`, having the new one generate
random `Components` with a 3072-bit modulus size, which is now the
`Default` for `KeySize`.
Add public accessor for the challenge hash component of ML-DSA
signatures, needed by hybrid schemes that share
the challenge across both classical and post-quantum components.
This renames the previous `generate` methods to
`try_generate_from_rng_with_key_size` and changes them to accept a
`TryCryptoRng`, returning a `Result` with potential RNG errors.
This helps clear the way for implementing the `Generate` trait from
`crypto-common`, which defines its own `generate` method which takes
no parameters, using the system RNG and default key size.
Enable `module-lattice/alloc` feature when the `alloc` feature is
enabled. With this change, users don't need to add an explicit entry
`module-lattice` at `Cargo.toml` to enable the `alloc` feature of the
`module-lattice` crate.
This also aligns with the behavior of the `ml-kem` crate.
This should be a true "release candidate" in that there are no
additional changes intended to be made before a final release, we're
just waiting for some final feedback on recent changes.
Adds an `alloc`-gated `verifying_key` field to `SigningKey`, and when
the feature is enabled precomputes the key at the time the `SigningKey`
is initialized.
We previously used to do this but stopped to optimize stack usage (see
the changes in #1259 and #1261), however when `alloc` is enabled this
isn't an issue since we've moved the relevant data to the heap in this
case (see #1344 and #1345), so stack usage is no longer an issue.
This makes it possible to implement `signature::KeypairRef` for
`SigningKey` which still provides a blanket `signature::Keypair` impl,
so we can always depend on the latter being availble but take advantage
of the former when `alloc` is enabled.
Opportunistically stores the parts of `SigningKey` on the heap when the
`alloc` feature is enabled, similar to what #1344 did for
`VerifyingKey`.
This also addresses #1308 by adding a `Drop` (and `ZeroizeOnDrop`) impl
to `SigningKey` which clears the `Seed`.
When the `alloc` feature is enabled, uses `Box` to offload the largest
parts of `VerifyingKey` to the heap.
This also extracts an internal `PrecomputedValues` struct to store the
largest components of the key, which are all derived/precomputed values,
as a single contiguous struct in a `MaybeBox`, and extracts some of the
relevant logic to it.
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.
Extracts a `SigningKey::from_seed` that was previously defined on
`MlDsaParams` via a trait impl.
This changes it to an inherent method, and has the trait method call the
inherent method.
This makes it possible to restrict the visibility of `SigningKey`
fields, addressing a TODO.
Extracts code previously in `lib.rs` related to the following types into
two modules:
- `signing`: `SigningKey`, `ExpandedSigningKey`
- `verifying`: `VerifyingKey`
Like #1324 did for `ed25519`, this uses the `serdect` crate for the
`serde` implementation, which is a breaking change.
See comments in #1324 for more information.
It's out-of-date and seemingly unused, possibly tied to the interop
documentation which is currently disabled, but we can cross that bridge
when we get there
Follows suit with `serde` support in other RustCrypto crates by using
`serdect` to implement `Serialize` and `Deserialize`, replacing the
previous use of `serde_bytes`.
These serializers use the `serdect::array` serializers which use
efficient format-specific byte encodings (albeit with a length prefix)
when serializing to binary formats, or a hex encoding with human
readable formats like JSON and TOML.
dependabot[bot]