-
Notifications
You must be signed in to change notification settings - Fork 84
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
Kirk baird patch 01 #79
Conversation
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you have this marked as a WIP so think of these as just some idle thoughts as I perused the PR. Thanks for doing this work.
okm = okm + previous | ||
|
||
# Return first `length` bytes. | ||
return okm[:length] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we discard the end of this can we exit early from the loop above once the condition okm >= length
is satisfied?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, though okm >= length
after n
iterators of the loop.
The loop could be changed to the condition while len(okm) < length
Then we would not have to calculate n
. However since it is following RFC5869 and that is the way it's mentioned there I think it'd be better to leave it with n
.
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Update: Sorry I've been off this for awhile I've been working on a couple of other things + DevCon but I'll finish implementing it from now. |
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Although this branch should now be usable there are a few things left todo:
Also worth noting that compression/decompression will need to be updated (currently looks like they will be made to match zcash). |
ISO_3_B = FQ2([1012, 1012]) | ||
ISO_3_Z = FQ2([1, 1]) | ||
P_MINUS_9_DIV_16 = 1001205140483106588246484290269935788605945006208159541241399033561623546780709821462541004956387089373434649096260670658193992783731681621012512651314777238193313314641988297376025498093520728838658813979860931248214124593092835 # noqa: E501 | ||
SQRT_I = 1028732146235106349975324479215795277384839936929757896155643118032610843298655225875571310552543014690878354869257 # noqa: E501 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some discomfort from having all of these constants floating around. Is there a formal/canonical spec that we can include a link to so that it's easy to reference/cross-check these constants are indeed the values they are supposed to be?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are soo many constants! Unfortunately they are necessary for the isogeny mapping.
Most of them come from
BLS General Constants: https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-04#section-8.7
ISO constants: https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-04#appendix-C.2
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Update: Version 5 of the hash-to-curve spec is out. I will update the code soon to match the new version. This is expected to be the last breaking change so hopefully won't be too long before we'll be able to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work!
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
I happy for this to be merged now :) Some final notes:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work! 🎉
I only tried to compare the code with the IETF spec instead of checking the math, and some nitpick.
temp2 = temp1 ** 2 * v - u | ||
if temp2 == FQ2.zero() and not valid_root: | ||
valid_root = True | ||
result = temp1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems okay to break
here.
result = temp1 | |
result = temp1 | |
break |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where I deliberate left it as a constant time implementation.
We could get some speed ups here if we were to remove those checks.
Ethereum does not need constant time hash to curve cause the messages are public so I'm happy to add the break statements in there if you would like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if this instinct is right but maybe lets leave this as constant time since that seems like a safe default.
We can track this in an issue as an option for performance improvements if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure I'll leave it as is and write-up an issue for it now.
Signed-off-by: Kirk Baird <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great works @kirk-baird!
This is my first pass of review.
Co-Authored-By: Chih Cheng Liang <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A question of Jacobian coordinates
Signed-off-by: Kirk Baird <[email protected]>
Signed-off-by: Kirk Baird <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My final review and some nitpick on reusing variables.
Signed-off-by: Kirk Baird <[email protected]>
Looks good, I'll add all of these! |
* repin flake8, bump tox to >=4.0.0 as that's where whitelist was deprecated, misc updates
What was wrong?
Updating the BLS
hash_to_G2
implementation to match the standard and ethereum/consensus-specs#1398How was it fixed?
Implement
hash_to_curve
for G2 which uses Boneh & Wahby method.There are three parts to this:
hash_to_field
- convert a message to a point in the finite field.map_to_curve
- SWU Map to 3-Isogenous Curve + 3-Isogeny Map to BLs12-318 G2clear_cofactor
- ensure that the point is in the correct subfield.Note: This is a Work In Progress PR to show progress and may not always be passing tests.
Cute Animal Picture