The backstory of these traits was once upon a time we didn't yet have
the trait structure in place to express algorithms like ECDSA signing
and verification generically, so each crate (at the time just `k256` and
`p256`) had a nearly duplicated implementation of ECDSA, with `k256`
including tweaks for low-S normalization.
Now the `ecdsa` crate contains fully generic implementations of both
algorithms, and with the `EcdsaCurve` trait, carries a `NORMALIZE_S`
preference, so these traits are just needless indirection at this point.
This removes the traits, converting non-trivial methods into static
functions in the `hazmat` module, namely `sign_prehashed_rfc6979`.
Moves the trait added in #787 out of the `hazmat` module and into the
toplevel, so it's available regardless of whether or not the `hazmat`
feature has been enabled.
This trait is the intended successor to the `SignPrimitive` and
`VerifyPrimitive` traits.
Currently the only reason for a non-default impl of those traits is to
handle low-S normalization. The `EcdsaCurve` trait now not only marks
the curve as being safe for use with ECDSA, but also captures this
decision regarding low-S normalization so it doesn't have to be
expressed in code.
RFC6979 Appendix A.1. provides a "Detailed Example" which exercises
several edge cases in the protocol:
- `bits2int` for an input which is not byte-aligned
- Rejecting inputs which exceed the modulus
This commit adds what was missing from the previous implementation which
assumed inputs were always aligned to the size of the digest output: a
constant-time right shift by the number of bits by which the modulus is
smaller than a byte-aligned value.
The RFC specifies this, however we were not performing it.
Going forward, it would be nice to be able to refactor these APIs to
operate over a `Scalar` which we know is always reduced.
Notably for curves like P-521, the digest used to compute the signature
is smaller than a serialized field element (SHA-512 w\ 64-byte output vs
66-byte serialized field elements).
To support such curves, we need to remove this bound.
The already implemented `bits2field` function as defined in
RFC6979 § 2.3.2 and SEC1 § 2.3.8 handles producing a serialized field
element from an input which may be a different size.
Adds an API which writes `k` into an output buffer rather than
allocating and returning it, which also accepts slices as inputs. This
makes it possible to use `rfc6979` to implement the `dsa` crate.
Also removes output size bounds on the underlying digest function, which
aren't actually relevant to the implementation at all since HMAC-DRBG
writes a variable-sized amount of output. This makes it possible to use
`rfc6979` + `ecdsa` in conjunction with `p521`, which has unusually
sized scalars (66-bytes) which don't match the output size of the
underlying digest function (SHA-512, which has a 64-byte output).
The method changed from `GenericArray::from_slice` to
`Array::ref_from_slice`.
This has been renamed back upstream in `hybrid-array` to simplify
people's upgrades, but for now we need to rename it until we can upgrade
`hybrid-array` again.
Longer term the method will be deprecated, so this is temporary anyway.
For `ecdsa` crate: MSRV is 1.73 due to a bump of `elliptic-curve` to
v0.14.0-pre.0.
This commit begins the next round of breaking changes and bumps all
crates to prerelease versions.
The main change in `signature` is an upgrade of the `digest` crate to
v0.11.0-pre.3, which is what brings the new MSRV 1.71 requirement.
Formats the `R` and `s` signature components as hexidecimal to make the
representation more compact, as requested in #723:
ed25519::Signature {
R: 0x3f3e3d3c3b3a393837363534333231302f2e2d2c2b2a29282726252423222120,
s: 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100,
}
When we enable the `std` feature and the `pkcs8` dependency is enabled (by the `pem` feature), enable the `std` feature of `pkcs8`.
This makes it easier to work with the re-exported `pkcs8::Error` type because without the `std` feature it does not impl the `std::error::Error` marker trait.