-
Notifications
You must be signed in to change notification settings - Fork 191
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
p521: field arithmetic implementation not working correctly #947
Comments
What's remaining in terms of tests before promoting this into a sem-ver feature |
When #951 lands we should basically be there, although I'd also like to wire up an ECDSA feature and add the Wycheproof test vectors for it |
Now that #946, #950, and #951 have landed it seems prudent to add a real `arithmetic` feature. This adds a feature similar to the other crates in this repo which exposes the following types which provide a curve arithmetic implementation: - `AffinePoint` - `ProjectivePoint` - `Scalar` The `wip-arithmetic-do-not-use` feature is now removed as well. While technically SemVer breaking, it wasn't supposed to be used in the first place! Closes #947
Now that #946, #950, and #951 have landed it seems prudent to add a real `arithmetic` feature. This adds a feature similar to the other crates in this repo which exposes the following types which provide a curve arithmetic implementation: - `AffinePoint` - `ProjectivePoint` - `Scalar` The `wip-arithmetic-do-not-use` feature is now removed as well. While technically SemVer breaking, it wasn't supposed to be used in the first place! Closes #947
Now that #946, #950, and #951 have landed it seems prudent to add a real `arithmetic` feature. This adds a feature similar to the other crates in this repo which exposes the following types which provide a curve arithmetic implementation: - `AffinePoint` - `ProjectivePoint` - `Scalar` The `wip-arithmetic-do-not-use` feature is now removed as well. While technically SemVer breaking, it wasn't supposed to be used in the first place! Closes #947
I see, are you working on this or should I create a pull request? |
I'm working on it. It's somewhat involved since the Fixing that will involve breaking changes to the |
Newtype for the curve's default hashing function that returns field element sized outputsize? |
Newtypes for |
Ah I see, so this eventually will require a breaking change in ecdsa crate. |
@MasterAwesome I was able to make the breaking changes in the
However, the |
This is a tracking issue for promoting
p521
'swip-arithmetic-do-not-use
feature to a workingarithmetic
feature.Notably the base field implementation in
p521
uses code generated byfiat-crypto
specific to Solinas primes, which is different from the Montgomery representation which is easily supported using macros in theprimeorder
crate.#945 fixed an issue where
fiat_p521_tight_field_element
uses a different limb representation thanU576
, however this was not sufficient to make the basic field arithmetic tests work: #946The text was updated successfully, but these errors were encountered: