ecdsa: add default impl of SignPrimitive::try_sign_prehashed
#396
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
Leverages the newly added `AffineXCoordinate` trait from RustCrypto/traits#817 to provide a default generic implementation of the ECDSA signature algorithm. Downstream crates can choose to override this implementation if they so desire, allowing them to potentially leverage more efficient arithmetic. This approach does have a disadvantage that it necessarily adds a `ScalarArithmetic<Scalar = Self>` bound on the curve, meaning that `SignPrimitive` can only be impl'd for a particular curve's scalar 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
added a commit
that referenced
this pull request
Nov 18, 2021
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
changed the title
SignPrimitive::try_sign_prehashedSignPrimitive::try_sign_prehashed
tarcieri
added a commit
that referenced
this pull request
Nov 18, 2021
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
added a commit
that referenced
this pull request
Nov 18, 2021
#397) 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.
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.
Leverages the newly added
AffineXCoordinatetrait from RustCrypto/traits#817 to provide a default generic implementation of the ECDSA signature algorithm.Downstream crates can choose to override this implementation if they so desire, allowing them to potentially leverage more efficient arithmetic.
This approach does have a disadvantage that it necessarily adds a
ScalarArithmetic<Scalar = Self>bound on the curve, meaning thatSignPrimitivecan only be impl'd for a particular curve's scalar 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.