Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

k256: normalize before calling is_odd() in sng0() #533

Merged
merged 1 commit into from
Mar 15, 2022

Conversation

fjarri
Copy link
Contributor

@fjarri fjarri commented Mar 15, 2022

An is_odd() call I forgot to address in #530

While this fixes the problem at hand, there are a couple of considerations:

  • To prevent future problems like this, we do need either k256: type safety for non-normalized field elements #531, or just auto-normalizing in FieldElement::is_odd() (but not in FieldElementImpl!). Originally I didn't do that because I wanted to leave a possibility for a slightly more efficient code (where the caller would know whether the value has been previously normalized or not), but perhaps it is not worth it, and it's better to prevent errors instead.
  • This was not caught in tests in k256: Do not normalize the argument in FieldElementImpl::is_odd() #530 because in CI we run tests with --release, and apparently this bug does not affect hash2curve test, which is the only one touching sgn0(). @tarcieri , why was that decision made originally?

@fjarri fjarri requested a review from tarcieri March 15, 2022 20:24
@tarcieri
Copy link
Member

tarcieri commented Mar 15, 2022

in CI we run tests with --release, and apparently this bug does not affect hash2curve test, which is the only one touching sgn0(). @tarcieri , why was that decision made originally?

Are you asking why CI runs the tests with --release?

We've had bugs in the past that only affected the release profile. An easy way to screw up is to perform some sort of effectful operation inside of a debug_assert! which is completely elided in a release build.

Release builds are what people actually use, so we test against them as they're more important.

We can potentially test both debug and release builds if you think that'd be helpful.

@fjarri
Copy link
Contributor Author

fjarri commented Mar 15, 2022

We can potentially test both debug and release builds if you think that'd be helpful.

I'm actually not sure now how it happened, because FieldElementImpl safety harness should have still been active when CI ran in #530 - but I see hash2curve test passing there, but if I run cargo test --all-features locally it fails. Yesterday I didn't notice it because I only ran cargo test with default features locally.

@fjarri
Copy link
Contributor Author

fjarri commented Mar 15, 2022

I hope it's not too much to ask to publish k256 0.10.4 with this? My library is using hash2curve, that's how I noticed this - in my own tests.

@tarcieri tarcieri merged commit ca49032 into RustCrypto:master Mar 15, 2022
tarcieri added a commit that referenced this pull request Mar 15, 2022
This release backports #533.

Since `master` is already v0.11 prereleases, this commit just contains
the release notes.

The released code can be found via the `k256/v0.10.4` tag:

https://github.com/RustCrypto/elliptic-curves/tree/k256/v0.10.4
@tarcieri
Copy link
Member

v0.10.4 released: #534

tarcieri added a commit that referenced this pull request Mar 15, 2022
This release backports #533.

Since `master` is already v0.11 prereleases, this commit just contains
the release notes.

The released code can be found via the `k256/v0.10.4` tag:

https://github.com/RustCrypto/elliptic-curves/tree/k256/v0.10.4
@fjarri fjarri deleted the is-odd-fix-part2 branch August 3, 2022 04:14
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