ecdsa: add hazmat primitives; remove/reverse curve dependencies #96
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tarcieri
changed the title
tarcieri
force-pushed
the
ecdsa/hazmat-primitives
branch
2 times, most recently
from
f8620cd to
3ed7d6d
Compare
Codecov Report
@@ Coverage Diff @@
## master #96 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 6 4 -2
Lines 209 179 -30
======================================
+ Misses 209 179 -30
Continue to review full report at Codecov.
|
This was referenced Jul 12, 2020
tarcieri
force-pushed
the
ecdsa/hazmat-primitives
branch
from
3ed7d6d to
a3aac91
Compare
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.
tarcieri
force-pushed
the
ecdsa/hazmat-primitives
branch
from
a3aac91 to
9eb75b4
Compare
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jul 14, 2020
The equivalents of these types used to live in the `ecdsa` crate, but were removed in this PR: RustCrypto/signatures#96 The goal of that PR was to reverse the previous relationship where the `ecdsa` crate depended on the `k256`/`p256`/`p384` crates, and instead have the curve implementation crates consume the `ecdsa` crate as an (optional) dependency. It makes each curve implementation a one-stop-shop for everything related to that curve, while allowing the ECDSA crate to provide some common functionality like ASN.1 (de)serialization, in addition to allowing it to export "primitive" traits which can be used with the goal of a reusable high-level ECDSA implementation which is generic over elliptic curves. This commit ports over equivalent types that were removed in `RustCrypto/signatures#96`, but also incorporates these changes: RustCrypto/signatures#98 Where the `ecdsa` crate previously had `Asn1Signature` and `FixedSignature` types generic over a curve, the PR above refactored it to make the "fixed" form the preferred `Signature` type, and refactoring ASN.1 DER support into an `ecdsa::asn1::Document` type. The nice advantage of that approach is it means the curve implementations no longer need to worry about an `Asn1Signature` type and can focus on `ecdsa::Signature` as the type they need to support.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Jul 14, 2020
The equivalents of these types used to live in the `ecdsa` crate, but were removed in this PR: RustCrypto/signatures#96 The goal of that PR was to reverse the previous relationship where the `ecdsa` crate depended on the `k256`/`p256`/`p384` crates, and instead have the curve implementation crates consume the `ecdsa` crate as an (optional) dependency. It makes each curve implementation a one-stop-shop for everything related to that curve, while allowing the ECDSA crate to provide some common functionality like ASN.1 (de)serialization, in addition to allowing it to export "primitive" traits which can be used with the goal of a reusable high-level ECDSA implementation which is generic over elliptic curves. This commit ports over equivalent types that were removed in `RustCrypto/signatures#96`, but also incorporates these changes: RustCrypto/signatures#98 Where the `ecdsa` crate previously had `Asn1Signature` and `FixedSignature` types generic over a curve, the PR above refactored it to make the "fixed" form the preferred `Signature` type, and refactoring ASN.1 DER support into an `ecdsa::asn1::Document` type. The nice advantage of that approach is it means the curve implementations no longer need to worry about an `Asn1Signature` type and can focus on `ecdsa::Signature` as the type they need to support.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds "hazmat" ECDSA signing and verification traits intended to be implemented by individual elliptic curve implementations:
SignPrimitive: intended to be implemented onScalarVerifyPrimitive: intended to be implemented onAffinePointThe 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
ecdsacrate has optional features fork256,p256, andp384.Instead, we can add an
ecdsafeature to thek256,p256, andp384crates 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 aforementioned hardware tokens).
This allows the
ecdsacrate 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.