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.
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