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`.
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.
Switches every crate except `slh-dsa` away from a direct `rand`
dependency they don't need. Right now we can't publish any crate that
directly depends on `rand`.
Uses a consistent default strategy for RNGs: `SysRng`, sourced from the
`getrandom` or as `rand::rngs::SysRng` in the case of `slh-dsa` which is
actually using `rand`-specific features.
If this causes too much of a slowdown, we can re-evaluate and go (back)
to `ChaCha8Rng` where needed for testing.
As discussed in RustCrypto/traits#1148, this uses
`&mut impl CryptoRngCore` as the API for passing CSRNGs.
This removes the need for a generic parameter in the type signature
while also keeping syntax to a minimum.
The traits in `signature` v2.0.0-pre.2 switched to these APIs. See
RustCrypto/traits#1147.
Implements the proposed breaking changes to the `signature` crate from
https://github.com/RustCrypto/traits/pull/1141
Most notably the `Signature` trait has been replaced with a
`SignatureEncoding` trait which permits an internally structured
signature representation.
For consistency with the `ecdsa` crate.
This naming scheme follows the philosophy that in a digital signature
scheme, it's clearer to name keys after their roles.
DSA admittedly benefits less than other schemes where there are other
potential algorithms that can be implemented using the same core
mathematics which share the same key representations.
Adds an initial implementation of DSA (see #8)
The following things work when tested against OpenSSL:
- The generated keys are valid and can be imported and exported from/to their DER/PEM representation
- Signatures generated by this library can be successfully verified
- Signatures can be imported and exported from/into their DER representation
- Signatures generated by OpenSSL can be successfully imported and verified
Tony Arcieri