getters for edwards point

[kevjue]

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

[tarcieri]

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]

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]

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]

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]

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

[str4d]

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

[tarcieri]

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

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