-
Notifications
You must be signed in to change notification settings - Fork 228
elliptic-curve: extract toplevel Curve trait
#223
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
Conversation
This is a fairly substantial refactoring of the `elliptic-curve` crate which extracts a toplevel `elliptic_curve::Curve` trait and redefines all types to use it. The `elliptic_curve::weierstrass::Curve` trait is maintained, but relegated to a marker trait. That said, it's still used as the marker trait for all traits/types defined in the `elliptic_curve::weierstrass` module. Notably the main thing this facilitates is making `SecretKey` generic around a `C: elliptic_curve::Curve` generic type. The previous impetus was to avoid directly associating types dependent on scalars with specific elliptic curves (rather the curve's order), but this is ultimately unhelpful as it precludes accounting for trait impls on the curve in trait bounds. With the new approach, we can use trait bounds to conditionally define methods on `SecretKey`, e.g. bounding a `SecretKey::generate` impl on curves which impl `Arithmetic where Self::Scalar: Generate`. This would eliminate the need for a special `GenerateSecretKey` trait. One other notable change is the associated type for computing type sizes for a particular curve has been renamed to `ElementSize`, rather than the previous `ScalarSize`. This hopefully captures that this size is for all elements related to a particular curve, i.e. both the base and scalar fields.
7f25738 to
005e578
Compare
|
Note: this is effectively complete, however I'm going to attempt to migrate the existing curve implementations to use it locally and make sure there isn't anything I've missed. |
Updates usages of the `elliptic-curve` crate API
Curve traitCurve trait
|
I did the updates to get the In both cases thanks to the existing type aliases, it was all fairly straightforward. Based on that, and unifying all of the types/traits as being generic around a single |
Updates usages of the `elliptic-curve` crate API
Updates usages of the `elliptic-curve` crate API
Updates usages of the elliptic-curve crate API to incorporate the changes from RustCrypto/traits#223.
Updates usages of the elliptic-curve crate API to incorporate the changes from RustCrypto/traits#223.
Updates usages of the elliptic-curve crate API to incorporate the changes from RustCrypto/traits#223.
Updates usages of the elliptic-curve crate API to incorporate the changes from RustCrypto/traits#223.
Updates usages of the elliptic-curve crate API to incorporate the changes from RustCrypto/traits#223.
Updates usages of the `elliptic-curve` crate API
This is a fairly substantial refactoring of the
elliptic-curvecrate which extracts a toplevelelliptic_curve::Curvetrait and redefines all types to use it.The
elliptic_curve::weierstrass::Curvetrait is maintained, but relegated to a marker trait. That said, it's still used as the marker trait for all traits/types defined in theelliptic_curve::weierstrassmodule.Notably the main thing this facilitates is making
SecretKeygeneric around aC: elliptic_curve::Curvegeneric type. The previous impetus was to avoid directly associating types dependent on scalars with specific elliptic curves (rather the curve's order), but this is ultimately unhelpful as it precludes accounting for trait impls on the curve in trait bounds.With the new approach, we can use trait bounds to conditionally define methods on
SecretKey, e.g. bounding aSecretKey::generateimpl on curves which implArithmetic where Self::Scalar: Generate. This would eliminate the need for a specialGenerateSecretKeytrait.One other notable change is the associated type for computing type sizes for a particular curve has been renamed to
ElementSize, rather than the previousScalarSize. This hopefully captures that this size is for all elements related to a particular curve, i.e. both the base and scalar fields.