elliptic-curve: generic impl of complete prime order formulas #1022
Conversation
Adds a generic implementation of the complete addition formulas from Renes-Costello-Batina 2015[1] adapted from @str4d's original implementation for the `p256` crate: RustCrypto/elliptic-curves#15 This implementation has been copied-and-pasted into the `p384` crate, hence the motivation to make it generic and extract it somewhere that it can be reused. The API exposed is fairly low-level, however it's difficult to better encapsulate it without making breaking changes to the `elliptic-curve` crate. Thus this PR opts to provide an initial low-level generic implementation with the goal of exploring removing more duplication with a higher-level API as followup work to be done at a time when breaking changes are permitted. [1]: https://eprint.iacr.org/2015/1060
| /// Affine point whose coordinates are represented by the given field element. | ||
| pub type AffinePoint<Fe> = (Fe, Fe); | ||
|
|
||
| /// Projective point whose coordinates are represented by the given field element. | ||
| pub type ProjectivePoint<Fe> = (Fe, Fe, Fe); |
There was a problem hiding this comment.
The use of coordinate tuples is to prevent confusion with the AffinePoint and ProjectivePoint types currently defined on a crate-by-crate basis (i.e. in p256 and p384)
Perhaps it would be possible in an eventual followup PR to extract a generic ProjectivePoint type which impls these formulas for C: PrimeCurve.
|
An unaddressed problem is testing the implementation in absence of a concrete curve implementation. Perhaps the |
Uses the generic implementation of Renes-Costello-Batina 2015 added to the `elliptic-curve` crate: RustCrypto/traits#1022
|
This PR adapts the |
Uses the generic implementation of Renes-Costello-Batina 2015 added to the `elliptic-curve` crate: RustCrypto/traits#1022
|
What about making a fully generic implementation of Weierstrass curves as I tried long ago with elliptic-curves/pull/218? |
|
@newpavlov yes, that would be the longer term goal, but as noted in the commit messages doing that effectively would require breaking changes which this implementation is trying to avoid for now. I can write up some potential designs. One would be changing |
Uses the generic implementation of Renes-Costello-Batina 2015 added to the `elliptic-curve` crate: RustCrypto/traits#1022
Uses the generic implementation of Renes-Costello-Batina 2015 added to the `elliptic-curve` crate: RustCrypto/traits#1022 This is effectively the same changes as #601 made to `p384`, but for the `p256` crate.
Uses the generic implementation of Renes-Costello-Batina 2015 added to the `elliptic-curve` crate: RustCrypto/traits#1022 This is effectively the same changes as #601 made to `p384`, but for the `p256` crate.
Uses the generic implementation of Renes-Costello-Batina 2015 added to the `elliptic-curve` crate: RustCrypto/traits#1022 This is effectively the same changes as #601 made to `p384`, but for the `p256` crate.
Adds a generic implementation of the complete addition formulas from Renes-Costello-Batina 2015 adapted from @str4d's original implementation for the
p256crate:RustCrypto/elliptic-curves#15
This implementation has subsequently been copied-and-pasted into the
p384crate (see RustCrypto/elliptic-curves#565), hence the motivation to make it generic and extract it somewhere that it can be reused.The API exposed is fairly low-level, however it's difficult to better encapsulate it without making breaking changes to the
elliptic-curvecrate. Thus this PR opts to provide an initial low-level generic implementation with the goal of exploring removing more duplication with a higher-level API as followup work to be done at a time when breaking changes are permitted.