...and remove masking scalar.
This API allows the inversion masking process to be handled outside of
the ECDSA implementation itself (potentially generically in a way that
can work across elliptic curves).
Adds a `dev` module ala the ones in the trait crates which contains
`new_signing_test` and `new_verification_test` macros which implement
a basic set of tests for implementers of `SignPrimitive` and
`VerifyPrimitive` respectively.
Ideally this would implement something close to the set of tests
described in the FIPS 186-4 ECDSA Validation System (ECDSA2VS), however
for now it tests basic signing, verification, and a verification failure
in the event the `s` component of the signature has an incorrect value.
Eventually it'd probably be good to convert to using `blobby` for
consistency with the other `dev` modules, however for now it specifies a
`TestVector` struct which the macros accept a slice of for vectors.
This commit renames `asn1::Document` to `asn1::Signature`.
This means we now have the following types:
- `ecdsa::Signature`: fixed-sized encoding
- `ecdsa::asn1::Signature`: ASN.1 DER encoding
Additionally this commit adds an impl of the `signature::Signature`
trait for `asn1::Signature`, promoting it back to a first-class
signature type. This allows ECDSA `signature::Signer` impls to directly
produce ASN.1 encoded signatures again without transcoding, if they
so desire.
The `DigestPrimitive` trait, intended to be implemented within a crate
which impls `elliptic_curve::weierstrass::Curve`, provides a blanket
impl of `PrehashSignature` for `ecdsa::Signature<C: Curve>`.
This is a small hack needed to work around the fact that the ECDSA
signature trait now lies in an external crate, so crates which implement
a specific curve can no longer impl traits on `ecdsa::Signature`.
The previous implementation had `Asn1Signature` and `FixedSignature`
types which sat side-by-side as equals.
However, that's annoying, because it means we need to do various work in
duplicate for both signature types.
It's also annoying because there's no "one true signature type" to reach
for.
The original motivations for doing this were a few different things:
- Initial implementation lacked transcoding necessitating the split
- Avoids unnecessary transcoding, which could preserve ASN.1 structures
Now that we have bidirectional transcoding between the formats, and
particularly one which should always serialize to "strict DER", it
seems like it's probably worth it to pay the transcoding costs and
"standardize" on the previous `FixedSignature` format as the blessed
`ecdsa::Signature` type.
This allows factoring everything ASN.1 related (besides a few helper
methods and a From-impl on Signature) into the `ecdsa::asn1` module
which everything else aside just feels cleaner than before.
This also means downstream ECDSA provider crates don't need to worry
about ASN.1 at all (unless they're e.g. parsing it from HSM/KMS output)
and can focus exclusively on the `ecdsa::Signature` type.
This commit isn't intended to be a release, but just bumps the version
number in Cargo.toml to `-pre` to distinguish it from the currently
released v0.6.1.
Several backwards incompatible / semver breaking changes have been
introduced since the release.
It also updates `elliptic-curve` to v0.5.0-pre, which was similarly
bumped to a `-pre` version in:
https://github.com/RustCrypto/traits/pull/215
Adds "hazmat" ECDSA signing and verification traits intended to be
implemented by individual elliptic curve implementations:
- `SignPrimitive`: intended to be implemented on `Scalar`
- `VerifyPrimitive`: intended to be implemented on `AffinePoint`
The traits are generic over elliptic curves, allowing one type to
potentially support multiple curves. This is potentially useful for
things like FFI bindings to multi-curve libraries, or host libraries for
hardware devices which support ECDSA signing for multiple elliptic
curves.
These traits must be consumed directly by elliptic curve
implementations, which means we need to reverse the current relationship
where the `ecdsa` crate has optional features for `k256`, `p256`, and
`p384`.
Instead, we can add an `ecdsa` feature to the `k256`, `p256`, and `p384`
crates which optionally pulls this crate in.
With the dependency relationship reversed, we can support an open ended
number of elliptic curves including 3rd party non-RustCrypto
implementations (as well as 3rd party ECDSA implementations ala
afforementioned hardware tokens).
This allows the `ecdsa` crate to focus on only the high-level details of
the ECDSA algorithm, like RFC 6979 deterministic signatures.
It also allows for wrapping complete ECDSA implementations, including
assembly optimized ECDSA primitives or things like hardware
accelerators.
...which wraps the underlying `k256` crate
People will ultimately be looking for "secp256k1" and `k256` is largely
an artifact of trying to use a crate name that wasn't taken and fit with
the other elliptic curve crates (`p256`, `k256`).
This should make it clearer.
Adds `normalize_s` method to `secp256k1::{Asn1Signature, FixedSignature}`
when the (new) `k256-arithmetic` feature is enabled.
This normalizes the s-component of ECDSA signatures in order to make
them non-malleable as describe din BIP 0062: Dealing with Malleability.
Adds a `[patch.crates-io]` directive so we can work off the latest
versions of the https://github.com/RustCrypto/elliptic-curves crates.
This is a breaking change for the `ecdsa` crate and makes it
unreleasable until releases of the elliptic curve crates happen,
but will allow us to implement a number of new features which require a
curve arithmetic implementation.
Uses the nightly-only `doc_cfg` feature to document which modules/types
are gated behind cargo features (namely `k256`, `p256`, and `p384`)
This is intended for use with https://docs.rs
Bumps the following crate dependencies, which all now depend on
`generic-array` v0.14:
- `elliptic-curve` v0.4.0
- `k256` v0.3.0
- `p256` v0.3.0
- `p384` v0.2.0
Also re-exports `generic-array` from the `elliptic-curve` crate rather
than depending on it directly, which simplifies upgrades.
Previously the serde serializer used `Serialize::serialize_bytes` which
accepts a slice and when serialized with e.g. bincode also includes a
length prefix on the signature. As it were, this made it incompatible
with the extant deserializer (and as such, this PR also adds much needed
serialization tests).
This commit changes the serializer to use the same internal
implementation as serde's own `array_impls`, i.e. signatures are
serialized as a tuple with 64 members.
Using this implementation, it means an Ed25519 signature serialized with
bincode is identical to `to_bytes()`, i.e. there is no redundant length
prefix.
Tony Arcieri