ecdsa: add default generic impl of VerifyPrimitive::verify_prehashed
#397
Conversation
This file contains hidden or 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
Similar to #396, this adds a generic implementation of ECDSA signature verification by providing a default implementation of the `VerifyPrimitive::verify_prehashed` method. Downstream crates can choose to override this implementation if they so desire, allowing them to potentially leverage more efficient arithmetic such as Shamir's trick / linear combinations (at least, until such a time as there are traits for these in the `group` crate). This approach does have a disadvantage that it necessarily adds a `AffineArithmetic<AffinePoint = Self>` bound on the curve, meaning that `VerifyPrimitive` can only be impl'd for a particular curve's affine point type, as opposed to the original design goal of allowing it to be impl'd for a hardware ECDSA accelerator that stores a private scalar. Either the default impl needs to be replaced with a blanket impl with more restrictive bounds, or a separate trait needs to be added to support hardware accelerators. The latter may indeed make the most sense.
tarcieri
force-pushed
the
ecdsa/default-verify-primitive-impl
branch
from
66f87b8 to
9250111
Compare
Merged
tarcieri
added a commit
that referenced
this pull request
Nov 18, 2021
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Nov 18, 2021
This updates the crates in this repo to leverage the following generic implementations recently added to the `ecdsa` crate: - Sign: RustCrypto/signatures#396 - Verify: RustCrypto/signatures#397 The `p256` crate is able to directly utilize the generic implementation from the `ecdsa` crate. The `k256` crate retains its previous custom implementation, which provides a secp256k1-specific take on public key recovery, but can also directly leverage optimizations for computing linear combinations, which there are not presently traits in `elliptic-curve` or `group` to express.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Nov 18, 2021
This updates the crates in this repo to leverage the following generic implementations recently added to the `ecdsa` crate: - Sign: RustCrypto/signatures#396 - Verify: RustCrypto/signatures#397 The `p256` crate is able to directly utilize the generic implementation from the `ecdsa` crate. The `k256` crate retains its previous custom implementation, which provides a secp256k1-specific take on public key recovery, but can also directly leverage optimizations for computing linear combinations, which there are not presently traits in `elliptic-curve` or `group` to express.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Nov 18, 2021
This updates the crates in this repo to leverage the following generic implementations recently added to the `ecdsa` crate: - Sign: RustCrypto/signatures#396 - Verify: RustCrypto/signatures#397 The `p256` crate is able to directly utilize the generic implementation from the `ecdsa` crate. The `k256` crate retains its previous custom implementation, which provides a secp256k1-specific take on public key recovery, but can also directly leverage optimizations for computing linear combinations, which there are not presently traits in `elliptic-curve` or `group` to express.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Nov 18, 2021
This updates the crates in this repo to leverage the following generic implementations recently added to the `ecdsa` crate: - Sign: RustCrypto/signatures#396 - Verify: RustCrypto/signatures#397 The `p256` crate is able to directly utilize the generic implementation from the `ecdsa` crate. The `k256` crate retains its previous custom implementation, which provides a secp256k1-specific take on public key recovery, but can also directly leverage optimizations for computing linear combinations, which there are not presently traits in `elliptic-curve` or `group` to express.
tarcieri
added a commit
to RustCrypto/elliptic-curves
that referenced
this pull request
Nov 18, 2021
This updates the crates in this repo to leverage the following generic implementations recently added to the `ecdsa` crate: - Sign: RustCrypto/signatures#396 - Verify: RustCrypto/signatures#397 The `p256` crate is able to directly utilize the generic implementation from the `ecdsa` crate. The `k256` crate retains its previous custom implementation, which provides a secp256k1-specific take on public key recovery, but can also directly leverage optimizations for computing linear combinations, which there are not presently traits in `elliptic-curve` or `group` to express.
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.
Similar to #396, this adds a generic implementation of ECDSA signature verification by providing a default implementation of the
VerifyPrimitive::verify_prehashedmethod.Downstream crates can choose to override this implementation if they so desire, allowing them to potentially leverage more efficient arithmetic such as Shamir's trick / linear combinations (at least, until such a time as there are traits for these in the
groupcrate).This approach does have a disadvantage that it necessarily adds a
AffineArithmetic<AffinePoint = Self>bound on the curve, meaning thatVerifyPrimitivecan only be impl'd for a particular curve's affine point type, as opposed to the original design goal of allowing it to be impl'd for a hardware ECDSA accelerator that stores a private scalar.Either the default impl needs to be replaced with a blanket impl with more restrictive bounds, or a separate trait needs to be added to support hardware accelerators. The latter may indeed make the most sense.