To get `serde` support for `VerifyingKey`, confusingly the `pem` feature
previously needed to be enabled (even though PEM is not actually used).
This changed the `serde` feature to auto-enable `pkcs8`, similar to
what was done in the `elliptic-curve` crate.
If the recovered public key isn't correct, an error occurs when comparing it to
the correct public key or public key hash. Therefore, we can skip this expensive
verification.
Replaces some manual branching and use of `unwrap()` with a more
combinator-like style.
This could benefit from it being easier to convert `CtOption` into
`Option`. See dalek-cryptography/subtle#119
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.
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,
}
Extracts generic, reusable functions from the `SignPrimitive` and
`VerifyPrimitive` traits.
The main motivation for this is to make it possible for the `*Primitive`
trait impls to be composed in terms of a generic implementation, in
order to add support for low-S normalization in the `k256` crate.
Implements `from_bytes` in terms of `from_scalars`, rather than the
other way around.
This places the logic for checking that `r` and `s` are nonzero inside
of the `from_scalars` method.
Additionally improves the documentation to note the various failure
cases, i.e. if `r` and/or `s` is out of the range `1..n`, where `n` is
the scalar modulus.
Uses `C::FieldBytesSize` instead of `C::Uint::BYTES`, which is needed
for curves like P-224 where the serialized field element may be smaller
than the bigint used to represent them.
This is needed to make curves like P-224 and P-521 work, since the size
of the `C::Uint` may not match the size of an integer serialization of a
field element (since `C::Uint::MAX` may be much larger than the field
modulus)
The implementation was adapted from `k256`, which produces signatures
with low-S normalization.
However, the provided implementation does not low-S normalize
signatures, so it should not be considered in the `RecoveryId`
computation.
Gated under a newly added `sha2` feature.
This implementation dispatches based on RFC5758 OIDs, selecting the
appropriate hash function to use at runtime based on the OID.
Adds support for obtaining the RFC5758 OIDs associated with the digest
algorithm used with the `Signer` and `Verifier` traits, i.e. the digest
defined via `DigestPrimitive::Digest` for a given curve.
The ECDSA OID is available via an `AssociatedOid` impl on `Signature`.
The `AlgorithmIdentifier` is also available via the newly added
`AssociatedAlgorithmIdentifier` trait.
Adds inherent methods for parsing a signature from `SignatureBytes<C>`
and a byte slice respectively.
The existing `TryFrom<&[u8]>` impl now calls `Signature::from_slice`.
These methods match similar inherent methods on other types.
Dan Cline