-
Notifications
You must be signed in to change notification settings - Fork 3
AffinePoint in LookupTable + NafLookupTable for Shamir's trick #19
Conversation
7a9623d
to
71e26d6
Compare
Use existing methods for cofactor clearing and torsion check
NAF based scalar mult with a window size of 5 seems to be even more efficient than the regular Lookup based scalar mult, hence relying on this for "vartime" methods. |
src/curve.rs
Outdated
if i == 0 { | ||
break; | ||
} | ||
|
||
i -= 1; |
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.
Is it more efficient to do it this way than to have e.g. for i in (0..i+1).rev()
?
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 it's the same, I'm afraid of readability here as i
refers to a loop indexed by i
, so I instead used for j in (0..i + 1).rev()
.
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 good to me.
This PR the internal type of points in
LookupTable
fromProjectivePoint
toAffinePoint
to benefit from faster mixed-addition. The performance difference is more important for multiplication with the hardcodedBASEPOINT_TABLE
, about 13% faster.It also integrates w-NAF conversion of Scalar elements for efficient Shamir's trick, useful in ECDSA or Schnorr signature verification.
The change to
AffinePoint
as internal type of the LookupTable requires the use oflazy_static!
to construct theBASEPOINT_TABLE
.closes #13
closes #14