-
Notifications
You must be signed in to change notification settings - Fork 133
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
Implement to/fromBits in TS, and set max length to 254 bits #1461
Conversation
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 will think more about the to/fromBits()
implementation and check the constraint count before I merge, but for now I just have a few questions about other things to make sure I'm on the right track! :)
* | ||
* @param length - the number of bits to fit the element. If the element does not fit in `length` bits, the functions throws an error. | ||
* | ||
* @return An array of {@link Bool} element representing little endian binary representation of this {@link Field}. | ||
*/ | ||
toBits(length?: number) { | ||
if (length !== undefined) checkBitLength('Field.toBits()', length); | ||
toBits(length: number = 254) { |
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 understanding is that there isn't a clever way to make this secure (other than just limiting it to 254 bits) because any other method would necessarily involve checking if the value overflowed or not. Does that reasoning check out?
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.
we could provide a secure, 255-bits version by treating the bits as a ForeignField
element and asserting that it's less than the field size. That would add some overhead so it's better to not do it by default. It could be a separate method toFullBits()
or similar. But not urgent IMO
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 makes sense. I will implement tomorrow if there is time.
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.
Ok, it looks like the number of rows for both methods is exactly the same as before (and the digest is identical for fromBits()
).
Let me know if I should add vk regression test for these methods; aside from that I think this is ready to merge if looks ok to reviewer :)
…happy" as this is handled in Scalar now This reverts commit c14178a.
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.
Looks great, just a few comments that should be addressed
Also @jackryanservia please add a changelog! Breaking change
"rows": 825, | ||
"digest": "226ff56f432f39d8056bf7f1813669f5" |
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.
1-row reduction makes sense because the hello-world example does privateKey.toPublicKey()
which as the final step converts the Group
(uncompressed EC point (x,y)
) into a PublicKey
(compressed EC point (x, isOdd)
) and to do that it needs to get all of y
's bits with toBits()
. toBits()
needs 1 row less now because it adds up 254 bits, not 255.
It does mean that certain public keys are no longer supported by this method. I think we should address that separately by introducing a dedicated parity()
gadget using range checks, which makes it more efficient as well
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 had wondered about this. Would it make sense to have this use toFullBits()
here in the meantime?
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.
Yes that would make sense
…urn value is referenced
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.
Nice work @jackryanservia !
Closes: #1023
toBits
andfromBits
methods in TS.Field.toBits()
andfromBits()
are unsound #1023