ecdsa: add CheckSignatureBytes trait + NonZeroScalar components#151
Conversation
Adds a `CheckSignatureBytes` trait with a default impl that ensures neither the `r` nor `s` components of a signature are all-zero. Includes a blanket impl of `CheckSignatureBytes` for all curves with the `Arithmetic` trait defined (and thus access to `C::Scalar`). This performs a better check that both `r` and `s` do not overflow the curve's order and are non-zero (using `NonZeroScalar`). Together these allow conditionally definining `ecdsa::Signature::r` and `::s` methods which permit infallible access to `NonZeroScalar<C>`, rather than the previous implementation which returns bytes. All of the above is a compromise which allows for crates which do not provide a curve arithmetic backend to still assert some checks on the signature values, but also ensure that signatures are well-formed, in-range scalars "automatically" when arithmetic is available.
Codecov Report
@@ Coverage Diff @@
## master #151 +/- ##
==========================================
- Coverage 60.51% 59.51% -1.01%
==========================================
Files 7 7
Lines 352 368 +16
==========================================
+ Hits 213 219 +6
- Misses 139 149 +10
Continue to review full report at Codecov.
|
| { | ||
| /// When curve arithmetic is available, check that the scalar components | ||
| /// of the signature are in range. | ||
| fn check_signature_bytes(bytes: &SignatureBytes<C>) -> Result<(), Error> { |
There was a problem hiding this comment.
The reason why this checks the signature as a whole rather than the individual components is it might make sense in some cases to have special-case handling of the individual components. The main case that comes to mind is EIP-2098 signatures. But this may be of dubious value, and it may still make more sense to have a "check scalar in range" trait which can be available even if a full curve arithmetic implementation is not.
Corresponding `ecdsa` crate PR is RustCrypto/signatures#151 This implements the changes which eagerly validate that ECDSA signature `r` and `s` components are in-range `NonZeroScalar` values. This eliminates the need to do these checks as part of each ECDSA verification implementation.
Corresponding `ecdsa` crate PR is RustCrypto/signatures#151 This implements the changes which eagerly validate that ECDSA signature `r` and `s` components are in-range `NonZeroScalar` values. This eliminates the need to do these checks as part of each ECDSA verification implementation.
Corresponding `ecdsa` crate PR is RustCrypto/signatures#151 This implements the changes which eagerly validate that ECDSA signature `r` and `s` components are in-range `NonZeroScalar` values. This eliminates the need to do these checks as part of each ECDSA verification implementation.
Adds a
CheckSignatureBytestrait with a default impl that ensures neither thernorscomponents of a signature are all-zero.Includes a blanket impl of
CheckSignatureBytesfor all curves with theArithmetictrait defined (and thus access toC::Scalar). This performs a better check that bothrandsdo not overflow the curve's order and are non-zero (usingNonZeroScalar).Together these allow conditionally defining
ecdsa::Signature::rand::smethods which permit infallible access toNonZeroScalar<C>, rather than the previous implementation which returns bytes.All of the above is a compromise which allows for crates which do not provide a curve arithmetic backend to still assert some checks on the signature values, but also ensure that signatures are well-formed, in-range scalars "automatically" when arithmetic is available.