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.
Includes changes to the `BoxedMontyForm::new` API, and also bumps
`crypto-primes` to v0.7.0-rc.6 which includes the associated updates
to that crate for the API change.
The `signature` test was too tightly coupled with the precise RNG
output, in effect not just testing the DSA signature/verification logic
but also testing that the exact bit sequence was produced by the
dependent crate.
We already have tests against deterministic keys and signatures at
`tests/deterministic.rs`, so modify `tests/signature.rs` to instead
generate a random keypair using the system RNG, then generate a
signature with that keypair, and then verify that signature.
The existing hard-coded signatures have been left in place as they are
used to test PKCS decoding and encoding.
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.
Makes `BoxedUint` the one unsigned integer type in the public API,
converting to `NonZero<BoxedUint>` and `Odd<BoxedUint>` as needed.
This makes the API simpler to use for end-users, with fewer types for
them to manage.
Closes#987
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