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

Expose primeOrder #259

Open
jeffallen opened this issue Dec 7, 2017 · 7 comments
Open

Expose primeOrder #259

jeffallen opened this issue Dec 7, 2017 · 7 comments

Comments

@jeffallen
Copy link
Contributor

From dedis/onet#256: Would it be possible to add a function to get the cardinality of the elliptic curve that is used ?

@jeffallen
Copy link
Contributor Author

David says: I would just need to be able to access primeOrder and primeOrderScalar or just (primeOrderScalar) that are in group/edwards25519/const.go. so maybe just an uppercase ? 🙂

@jeffallen jeffallen changed the title Cardinality of the Elliptic Curve Expose primeOrder Dec 7, 2017
@jeffallen jeffallen removed their assignment Dec 7, 2017
@nikkolasg
Copy link
Collaborator

I would maybe suggest that david makes a copy of that variable inside his own code if "Only wants that value" and not the cardinality for all possible groups. Only a suggestion...

@ineiti
Copy link
Member

ineiti commented Dec 7, 2017

In Javascript and Java I had to access that value for different reasons, so it is definitively something that will be used if it's exposed. Can we put that into some generic parameter-readonly field or a method?

@bford
Copy link
Contributor

bford commented Dec 7, 2017

It might be worth adding an (optional) interface somewhere by which a caller can query multiple curve parameters that may be of interest in different circumstances, such as (a) the curve order, (b) the order of the underlying field used in the curve's representation, (c) the large prime and cofactor (possibly 1) comprising the curve's order.

@jeffallen
Copy link
Contributor Author

It is not clear enough what we expect here, and there are easy workarounds if David needs them.
So not going in kyber v1.

@pierluca
Copy link
Contributor

It seems that the use cases discussed in this issue have found workarounds.

@si-co do you think we should leave this open, or shall we close it as part of the ongoing clean-up ?

@si-co
Copy link

si-co commented Nov 28, 2022

The optional interface proposed by @bford would be useful and not difficult to implement, but since there are workarounds and given the multiple urgent issues in the repo I'd close (for now).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants