Implementation of elliptic-curve traits for curve25519 and ed25519.
#746
Conversation
impl Ord for Scalar
|
@carloskiki there will hopefully be a v0.14 release of
This would probably make the most sense as a way to support the current Perhaps the |
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`).
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`).
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`).
* 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
…ations" This reverts commit bff18e4.
|
|
||
| /// QUESTION: I don't know where to put this singleton. Maybe in the crate's root? | ||
| #[derive(Clone, Copy, Debug, Default, Eq, PartialEq, PartialOrd, Ord, Hash)] | ||
| pub struct Ed25519; |
There was a problem hiding this comment.
Ed25519 is the name of the EdDSA variant.
RFC7748 calls the Edwards form of the curve "edwards25519"
|
I opened RustCrypto/traits#1900 to see if there would be interest in using a single In the mean time we may want to wait to implement these traits, especially for |
|
|
||
| use crate::{constants::BASEPOINT_ORDER_PRIVATE, edwards::affine::AffinePoint, EdwardsPoint, Scalar}; | ||
|
|
||
| /// QUESTION: I don't know where to put this singleton. Maybe in the crate's root? |
There was a problem hiding this comment.
I'd probably put it in edwards.rs
|
@carloskiki I think it's fine to impl them just for |
* 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
The driving reason for implementing this is to eventually implement the
hash2curvetraits for elligator2.See also: #612, #492.
Main Concern for
Ed25519The
CurveArithmetictrait requires anAffinePointfor which this crate only hasCompressedEdwardsY. The problem is thatCurveArithmeticrequires an Infallible conversion fromAffinePoint(CompressedEdwardsY) toProjectivePoint(EdwardsPoint).Currently, this implementation skips the fallible implementation of
CompressedEdwardsY->EdwardsPointand creates an invalidEdwardsPointifCompressedEdwardsYis invalid (we probably don't want this).I can think of 2 other solutions:
pub AffineEdwardsPoint { x: FieldElement, y: FieldElement }(with private internals) to implementCurve&CurveArithmetic. I believe this would not be a breaking change.CompressedEdwardsYprivate (Breaking change), and introduce a type alias for the the wire representation ofCompressedEdwardsYe.g.:CompressedEdwardsYwould require validation and would be fallible.See also: Should
CompressedEdwardsYguarantee validity? #745.Main Concern for
Curve25519:It does not seem like there is a public
ProjectivePointforcurve25519. One solution would be to make the current one public.Note
Only
Ed25519has the traits implemented (hence why this is a draft), but I would like feedback on this implementation, as I feel the implementation forCurve25519will have similar issues. The code containsQUESTIONs that explain the issues faced.Both
Ed25519andCurve25519will be housed in the cratecurve25519, since this is where the arithmetic is implemented for both curves.