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

improve: avoid the inversions in iso_map_secp256k1 #124

Conversation

duguorong009
Copy link
Contributor

Description

Improve the iso_map_secp256k1 func by avoiding the scalar inversions at all.

Related issues

Changes

  • use the jacobian coordinates instead of affine one in the func
  • update the iso_map logic by using jacobian coordinates

@davidnevadoc davidnevadoc self-requested a review January 9, 2024 12:31
Copy link
Contributor

@davidnevadoc davidnevadoc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👍

Just a couple of suggestions:

  1. Let's add an RFC reference for this modification https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html#section-appendix.e

  2. I think we no longer need to follow the naming convention for the constants K since we are following a different algorithm. I would remove the first [Fp::ZERO, 4] and add a comment specifying that K[0][..] are x_num constants, K[1][..] are x_den constants, ...

These suggestions are optinal, feel free to merge!

@CPerezz
Copy link
Member

CPerezz commented Jan 9, 2024

Can we try to merge this prior to the release in #125 ??

@duguorong009
Copy link
Contributor Author

LGTM! 👍

Just a couple of suggestions:

  1. Let's add an RFC reference for this modification https://www.ietf.org/archive/id/draft-irtf-cfrg-hash-to-curve-10.html#section-appendix.e
  2. I think we no longer need to follow the naming convention for the constants K since we are following a different algorithm. I would remove the first [Fp::ZERO, 4] and add a comment specifying that K[0][..] are x_num constants, K[1][..] are x_den constants, ...

These suggestions are optinal, feel free to merge!

Thanks for quick review! @davidnevadoc

  1. We already have the RFC reference in here.
  2. Even though we use the algorithm to avoid inversion, the constants meanings are not different from original one.
    I think it is okay to keep the current K as is.

Hence, I would go for merge!

@duguorong009
Copy link
Contributor Author

Can we try to merge this prior to the release in #125 ??

Yes, I will merge the PR right now since @davidnevadoc gave approval.

@duguorong009 duguorong009 added this pull request to the merge queue Jan 10, 2024
Merged via the queue into privacy-scaling-explorations:main with commit 8c93a25 Jan 10, 2024
11 checks passed
@duguorong009 duguorong009 deleted the gr@improve-iso-map-secp256k1 branch January 10, 2024 01:37
@duguorong009 duguorong009 mentioned this pull request Jan 10, 2024
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.

3 participants