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

Curve crate #84

Closed
kayabaNerve opened this issue Aug 13, 2022 · 3 comments
Closed

Curve crate #84

kayabaNerve opened this issue Aug 13, 2022 · 3 comments
Labels
cryptography An issue involving cryptography/a cryptographic library feature New feature or request improvement This could be better

Comments

@kayabaNerve
Copy link
Member

A Curve trait, similar to ff/group (and defined over ff/group), yet offering a variety of provided methods (*_len, read_*) and requiring Zeroize would be appreciated.

Offering a hash_to_F would also be appreciated, yet the issue is how hash_to_F varies across curves. Ed25519 does it raw, secp256k1 does ExpandMessageXMD. While an IETF hash_to_curve implementation composable for anything implementing ff/group would be appreciated, it still needs to be selected per-curve, where-as I'd like to keep the Curve trait incredibly minimal (ideally impl Curve for Group).

Perhaps:

  • Curve
  • ZeroizeCurve
  • HashToCurve
  • ZeroizeCurve + HashToCurve (SeraiCurve? FeaturedCurve? CompleteCurve?)

Would be quite minimal, yet de-duplicates code as does #83.

@kayabaNerve kayabaNerve added feature New feature or request improvement This could be better cryptography An issue involving cryptography/a cryptographic library labels Aug 13, 2022
@kayabaNerve
Copy link
Member Author

Generator overriding is also required.

@kayabaNerve
Copy link
Member Author

Worked on in https://github.com/serai-dex/serai/tree/curve.

@kayabaNerve kayabaNerve mentioned this issue Aug 14, 2022
2 tasks
@kayabaNerve
Copy link
Member Author

It should be possible to define a sufficiently sane generator API by just not doing so. If we instead define a Curve which uses a static for its generator, and then we allow overriding it at runtime, using RAII to pop back the old value...

Such a design would be blocked by zkcrypto/group#32 if we ever attempted it with Group directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cryptography An issue involving cryptography/a cryptographic library feature New feature or request improvement This could be better
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant