curve: extract AffinePoint type
#769
Conversation
Based on discussions about `elliptic-curve` trait impls in #746, and observing a similar type in `ed448-goldilocks` which inspired this one (not to mention in all of the @RustCrypto elliptic curve crates), adds an `AffinePoint` type with `x` and `y` coordinates. For now, the type is kept out of the public API, and used as an implementation detail for point compression. However, it's been written with the intent of eventually stabilizing and exposing it. It's been marked `pub` so unused functionality doesn't automatically trigger dead code lints. Further work could include refactoring point decompression to first produce an `AffinePoint` and then convert to extended twisted Edwards coordinates (i.e. `EdwardsPoint`), which is more or less what the existing `step_1` and `step_2` functions do (`step_1` technically produces projective coordinates, but `Z` is always set to `ONE`).
tarcieri
force-pushed
the
curve/edwards-affine
branch
from
44d86ab to
cdf999e
Compare
* curve: extract `AffinePoint` type Based on discussions about `elliptic-curve` trait impls in #746, and observing a similar type in `ed448-goldilocks` which inspired this one (not to mention in all of the @RustCrypto elliptic curve crates), adds an `AffinePoint` type with `x` and `y` coordinates. For now, the type is kept out of the public API, and used as an implementation detail for point compression. However, it's been written with the intent of eventually stabilizing and exposing it. It's been marked `pub` so unused functionality doesn't automatically trigger dead code lints. Further work could include refactoring point decompression to first produce an `AffinePoint` and then convert to extended twisted Edwards coordinates (i.e. `EdwardsPoint`), which is more or less what the existing `step_1` and `step_2` functions do (`step_1` technically produces projective coordinates, but `Z` is always set to `ONE`). * Update curve25519-dalek/src/edwards.rs
|
I was considering a PR to support deserialization of uncompressed points, as I'm currently paying a notable performance penalty reading points from a binary (generated at compile-time) for no reason when I found this PR. As a note, I'd love for a public AffinePoint I can load an x/y coordinate into and convert into a EdwardsPoint. |
|
@kayabaNerve you're fine with it still checking the coordinates are a valid solution to the curve equation, right? (it would still avoid the I would be okay with a public checked constructor like that, when and if we do decide to make |
|
Of course. The few multiplications there are <5% of the sqrt though 😅 |
|
@kayabaNerve want to open a PR for discussion to export |
|
Working on this after #787. It presumably will have to build upon that, unless we define the coordinates as |
Based on discussions about
elliptic-curvetrait impls in #746, and observing a similar type ined448-goldilockswhich inspired this one (not to mention in all of the @RustCrypto elliptic curve crates), adds anAffinePointtype withxandycoordinates.For now, the type is kept out of the public API, and used as an implementation detail for point compression. However, it's been written with the intent of eventually stabilizing and exposing it. It's been marked
pubso unused functionality doesn't automatically trigger dead code lints.Further work could include refactoring point decompression to first produce an
AffinePointand then convert to extended twisted Edwards coordinates (i.e.EdwardsPoint), which is more or less what the existingstep_1andstep_2functions do (step_1technically produces projective coordinates, butZis always set toONE).