Skip to content

ecdsa: add CheckSignatureBytes trait + NonZeroScalar components#151

Merged
tarcieri merged 1 commit into
masterfrom
ecdsa/check-signature-bytes
Sep 4, 2020
Merged

ecdsa: add CheckSignatureBytes trait + NonZeroScalar components#151
tarcieri merged 1 commit into
masterfrom
ecdsa/check-signature-bytes

Conversation

@tarcieri

@tarcieri tarcieri commented Sep 3, 2020

Copy link
Copy Markdown
Member

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 defining 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.

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-commenter

Copy link
Copy Markdown

Codecov Report

Merging #151 into master will decrease coverage by 1.00%.
The diff coverage is 57.57%.

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
ecdsa/src/lib.rs 47.27% <53.33%> (-4.01%) ⬇️
ecdsa/src/asn1.rs 69.36% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bddc23d...0930874. Read the comment docs.

Comment thread ecdsa/src/lib.rs
{
/// 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> {

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@tarcieri tarcieri merged commit 473af25 into master Sep 4, 2020
@tarcieri tarcieri deleted the ecdsa/check-signature-bytes branch September 4, 2020 00:00
tarcieri added a commit that referenced this pull request Sep 4, 2020
tarcieri added a commit that referenced this pull request Sep 4, 2020
tarcieri added a commit to RustCrypto/elliptic-curves that referenced this pull request Sep 4, 2020
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.
tarcieri added a commit to RustCrypto/elliptic-curves that referenced this pull request Sep 4, 2020
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.
tarcieri added a commit to RustCrypto/elliptic-curves that referenced this pull request Sep 4, 2020
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.
@tarcieri tarcieri mentioned this pull request Sep 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants