Closed omershlo closed 5 years ago
@burdges thanks for the answer. But I must say I didn't understand it. There should not suppose to be any problem to use ristretto to implement digital signatures and in some of them (ecdsa for example) we need x coordinate. x coordinate is well defined for ed25519 curve and any other elliptic curve. What's wrong with https://doc.dalek.rs/src/curve25519_dalek/ristretto.rs.html#249 ?
@omershlo I'm curious why you would want to use ECDSA in combination with Ristretto. Now that the Schnorr patent has expired, Schnorr signatures (e.g. EdDSA) are generally preferred in new designs. ECDSA's design (and vicariously DSA's design) are they way they are in order to avoid the Schnorr patent.
Is there a specific property of ECDSA you want, or are you just looking for a way to create signatures with Ristretto?
I'm unfamiliar with anyone using ECDSA with anything besides (short) Weierstrass curves, aside from the "FrankenECDSA" ECDSA-in-Edwards concept briefly explored by the CFRG (i.e. use Edwards x-coordinate mod l as r), but with the Schnorr patent expired it makes little sense to pursue such an approach.
I certainly don't want to use ECDSA in combination with ristretto :)
my claim is simple - right now it is not possible to extract/ calculate the x coordinate of a point. And my question is if you can allow some way to do it? (or if there is a way that I didn't find).
I accept @burdges claim that hash of compressed ristretto will work for many cases and that there should not be an API for x coordinate. But this is the first elliptic curve library that I looked into that you can't even calculate to x-coor yourself if you really really really want to.
right now it is not possible to extract/ calculate the x coordinate of a point
Yup! Ristretto doesn't provide an elliptic curve, it provides an abstract group, so all you can ask for is the canonical encoding. This provides safety benefits, but allows a lot of implementation flexibility -- implementations aren't even required to use Curve25519 internally!
But this is the first elliptic curve library that I looked into that you can't even calculate to x-coor yourself if you really really really want to.
Excellent, that's one of the safety properties we were aiming to provide.
got it. Thanks for the insightful discussion!
It's not considered well defined because a non-cannonical choice gets made by the ristretto implementation. It risks only partially compliant implementations if one specifies a particular choice and exposes the mapping to the curve. The way ristretto does it avoids messes, requires less from users, etc. You'll want to hash the
CompresedRistretto
instead most likely.