Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

what is the best way to get the x coordinate of a ristretto point ? #235

Closed
omershlo opened this issue Feb 23, 2019 · 6 comments
Closed

Comments

@omershlo
Copy link

No description provided.

@burdges
Copy link
Contributor

burdges commented Feb 23, 2019

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.

@omershlo
Copy link
Author

@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 ?

@tarcieri
Copy link
Contributor

tarcieri commented Feb 24, 2019

@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.

@omershlo
Copy link
Author

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.

@hdevalence
Copy link
Contributor

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.

@omershlo
Copy link
Author

got it. Thanks for the insightful discussion!

pinkforest pushed a commit to pinkforest/curve25519-dalek that referenced this issue Jun 27, 2023
This enables activating the `alloc` and `std` features without
unnecessarily pulling in optional dependencies like `rand` and `serde`.

It also fixes tests for `--no-default-features` (w\ `--lib` only)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants