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

getters for edwards point #553

Conversation

kevjue
Copy link

@kevjue kevjue commented Jul 25, 2023

This PR adds simple getter functions for the EdwardsPoint's fields.

@tarcieri
Copy link
Contributor

This crate deliberately does not expose FieldElement in the public API because it’s “unsafe” in the cryptographic sense. Aside from protocols that operate directly on coordinates (e.g. hash2curve) it should be possible to implement protocols in terms of group-based abstractions.

Is there a specific protocol or use case you had in mind which necessitates this?

@kevjue
Copy link
Author

kevjue commented Jul 27, 2023

This crate deliberately does not expose FieldElement in the public API because it’s “unsafe” in the cryptographic sense. Aside from protocols that operate directly on coordinates (e.g. hash2curve) it should be possible to implement protocols in terms of group-based abstractions.

Is there a specific protocol or use case you had in mind which necessitates this?

Thanks for the quick reply @tarcieri. The reason why we want to retrieve those fields is that we are representing the points in a different representation.

More specifically, we want to represent elliptical curve points within a SNARK circuit. In case you are not familiar with SNARKs, they require that a program is defined as an arithmetic circuit where each wire of the circuit is of only one type (one way to think of this is that all wires are u64 type).

So we are using your crate to do all the actual EC operations, but then want to convert your EC representation into our circuit representation afterwards.

By the way, we are using this crate for creating our SNARK circuit: https://github.com/mir-protocol/plonky2.

@tarcieri
Copy link
Contributor

There's a general problem surrounding coordinate access which impacts both this crate and several others (e.g. NIST and secp256k1 crates maintained by @RustCrypto).

Here's a tracking issue for traits for coordinate access in the group crate (see #473): zkcrypto/group#30

I would probably suggest coordinate access through such a (prospective) trait-based API rather than through inherent methods.

@dconnolly
Copy link

There's a general problem surrounding coordinate access which impacts both this crate and several others (e.g. NIST and secp256k1 crates maintained by @RustCrypto).

Here's a tracking issue for traits for coordinate access in the group crate (see #473): zkcrypto/group#30

I would probably suggest coordinate access through such a (prospective) trait-based API rather than through inherent methods.

@str4d may have opinions from both sides of this sort of api

@str4d
Copy link
Contributor

str4d commented Jul 27, 2023

Yeah, it's high time we solved this. I'll take some time during Zcon4 to work up a proposal.

@str4d
Copy link
Contributor

str4d commented Jul 30, 2023

Here's my initial proposal: zkcrypto/group#49 (built on zkcrypto/group#48).

@tarcieri
Copy link
Contributor

@kevjue can you take a look at the API in @str4d's proposal above and let us know if it will work for your use cases?

Do you actually need the extended twisted Edwards coordinates, or would affine or projective coordinates do? (you could recompute the extended twisted Edwards coordinates if needed)

@tarcieri
Copy link
Contributor

We can implement @str4d's proposal when it lands.

In the meantime, I don't think we'll be directly exporting the extended twisted Edwards coordinates like this

@tarcieri tarcieri closed this Aug 28, 2023
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

Successfully merging this pull request may close these issues.

4 participants