Open str4d opened 4 years ago
Hey @str4d, thanks for looking into the code! For Ristretto we are using curve25519-dalek which I belive is an instantiation of Ristretto for curve25519.
curve25519-dalek is a library providing group operations on the Edwards and Montgomery forms of Curve25519, and on the prime-order Ristretto group.
What am I missing?
About the x/y coordinates - I agree, there's an error there. In practice we never use the coordinates so I think we will make it unimplemented as well. However, I don't see how it relates to your first point?
For Ristretto we are using curve25519-dalek which I belive is an instantiation of Ristretto for curve25519.
curve25519-dalek
is implementing ristretto255
as specified in the RFC draft. It happens to use the Edwards form of Curve25519 as its internal representation, but that is an internal implementation detail, not exposed as part of the Ristretto API.
curve25519-dalek is a library providing group operations on the Edwards and Montgomery forms of Curve25519, and on the prime-order Ristretto group.
What am I missing?
Exactly as that documentation says, it provides group operations on the Curve25519 elliptic curve, and on the prime-order Ristretto group.
I strongly recommend reading the ristretto255
RFC draft, but quoting two relevant sections:
Ristretto implements an abstract prime-order group interface that exposes only the behavior that is useful to higher-level protocols, without leaking curve-related details and pitfalls.
ristretto255 is an abstraction which implements a prime-order group, and ristretto255 elements are represented by curve points, but they are not curve points.
In short, ristretto255
not an elliptic curve, and therefore the ECPoint
trait should not be implemented for it, as that trait is intended for elliptic curves (as documented in this crate). A more generic group trait (such as the one I am currently working on for the group
crate) would make sense for both ristretto255
and the various elliptic curves, but users of the ECPoint
trait can reasonably assume that they will only be given elliptic curves, not generic groups.
I see your point. You are concerned because we named the trait in this library ECPoint
, is that right?
This is probably a bad naming issue because this trait aims to offer an interface for generic group element (I admit that it might not be the most accurate set of operation required but this is what we needed for our generic ECC [put aside the issue with coordinates for a second]).
When you use this outside this is the names you see:
pub type GE = Secp256k1Point;
pub type FE = Secp256k1Scalar;
If we were to rename ECPoint
to something more generic over groups, would it solve the issue?
I noticed today that the
curv
traits are implemented forristretto255
.ristretto255
is an abstract group, not an elliptic curve. See the ristretto255 RFC draft for more details. Thecurv
traits provide APIs for elliptic curves, and thus it is a type error to implement them forristretto255
.I briefly looked at the trait implementation, and found an example of where the type error manifests as an implementation error:
https://github.com/KZen-networks/curv/blob/b326b2708560eaa0e8fd86f2c2d7d20d6eafbdce/src/elliptic/curves/curve_ristretto.rs#L278-L289
Besides the fact that
ristretto255
elements do not have coordinates, this code is parsing an encodedristretto255
element (which includes the representation of a field element modulo p = 2255 - 19) as aristretto255
scalar (which are field elements modulo ℓ = 2252 + 27742317777372353535851937790883648493), which is a type error, and returns a scalar that has been reduced from a field element, losing information.