-
Notifications
You must be signed in to change notification settings - Fork 358
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
10 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e102a69
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 believe you don't need the value
_maxwellAdjust
any more. Instead, the loop will terminate whenxc
exceeds the field modulus value.It seems like you could have combined the top part of the function into the loop to reduce duplicate code. Maybe you didn't do that because you want to avoid the
x.clone()
for performance? If so it would be good to add comments to that effect.Keeping in mind that I'm completely unfamiliar with this code and I'm not a JS coder, this seems to do the right thing. I'm working on adding the test vectors to ring. I'll ping you when they're ready so you can use them here. Note that libsecp256k1 has a test vector for that curve: see bitcoin-core/secp256k1@32600e5#diff-4655d106bf03045a3a50beefc800db21R1003.
e102a69
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.
Also, you titled the commit "optimize Maxwell's trick", but my suggestion isn't about performance. It's about making sure that the code using the trick has exactly the same semantics as the normal code that does Jacobian-to-affine conversion.
In particular, consider the following two cases, using n == 5 and q == 7.
Case 1:
r < q - n
. In this case, it is possible that the original affine x coordinate was eitherr
orr + n
, both of which reduce tor
mod n. For example, ifr == 1
thenx
might be either1
(r
) or6
(r + n
) for a valid signature.Case 2:
r >= q - n
. In this case, the affinex
coordinate must have beenr
. There is no other value ofx
wherex % n
==r
. For example, ifr == 3
then it must be the case thatx == 3
if the signature is valid. Note thatr + n (mod q)
==3 + 5 (mod 7)
==8 (mod 7)
==1
! (This is based on my understanding thatrx.redIAdd(t);
in your code is reducing modq
, not modn
.)e102a69
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.
@briansmith thank you for the comment! I believe you a right. Here is my reasoning:
Original comparison:
This means that technically
p.x
could be:Where
i
is either positive or negative integer with the only requirement that the0 <= p.x <= curve.prime
. Imposing this requirement and observing thatr
is alwaysr < curve.order
-i
can be only positive. Therefore we need to check all values ofi
from0
to whatever it takes to getr + i * order
maximally close to the curve's prime. Checking it further than that will have a different semantics indeed.Going to remove the
._maxwellAdjust
comparison, thank you!e102a69
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 what I have in mind for the patch:
Regarding merging stuff, I'll iterate on it a bit later. Thank you again!