-
Notifications
You must be signed in to change notification settings - Fork 86
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
Constant-time EC point multiplication (Montgomery ladder) implementation #325
base: main
Are you sure you want to change the base?
Changes from 20 commits
130b977
6049ea4
e00a891
3e9e54b
cd3156e
06e941c
4b51e44
29638d5
880812c
681239e
1bfffd4
bd67b35
c5e836d
6270ad5
fe22dac
6665e36
fc0f3b8
8127d10
3c122c5
56fcd9f
b7dec5b
f0ad8e1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -65,25 +65,34 @@ export function addPoint(p1: Point<bigint>, p2: Point<bigint>): Point<bigint> { | |
/** | ||
* Performs a scalar multiplication by starting from the 'base' point and 'adding' | ||
* it to itself 'e' times. | ||
* This algorithm is called 'Montgomery Ladder'. See {@link https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Montgomery_ladder} | ||
* This works given the following invariant: At each step, R0 will be r_0*base where r_0 is the prefix of e | ||
* written in binary and R1 will be (r_0+1)*base. In other words: at iteration i of the loop, r_0's binary | ||
* representation will be the first i+1 most significant bits of e. If the upcoming bit is a 0, we just have to | ||
* double R0 and add R0 to R1 to maintain the invariant. If it is a 1, we have to double R0 and add 1*base | ||
* (or add R1, which is the same as (r_0+1)*base), and double R1 to maintain the invariant. | ||
* @param base The base point used as a starting point. | ||
* @param e A secret number representing the private key. | ||
* @returns The resulting point representing the public key. | ||
*/ | ||
export function mulPointEscalar(base: Point<bigint>, e: bigint): Point<bigint> { | ||
let res: Point<bigint> = [Fr.e(BigInt(0)), Fr.e(BigInt(1))] | ||
let rem: bigint = e | ||
let exp: Point<bigint> = base | ||
|
||
while (!scalar.isZero(rem)) { | ||
if (scalar.isOdd(rem)) { | ||
res = addPoint(res, exp) | ||
e %= order | ||
ChinoCribioli marked this conversation as resolved.
Show resolved
Hide resolved
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looking at this again, the original implementation doesn't make any assertions or modifications to this variable. This is an exponent, which is not necessarily a field element, so the reduction should be unnecessary. I think if we remove this we have a pretty safe function. We just need to look more deeply at the performance hit and decide if it's worth it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An exponent doesn't have to be a field element, but the curve is cyclic with its order, so a value greater than the order is redundant compared to the modular reduction of the same value (either leads to the same output). And the constant-ish time algorithm below works only if you can fix the number of bits in the input. If we reduce the modular reduction, then I think this function becomes incorrect for any value greater than the order. Modular reduction is not the same as cutting off high bits (because the order is not a power of 2). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed. As Andrew says, some tests break when you remove the reduction because you incorrectly handle the case where the exponent passed as input is greater than 254 bits. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah right because the loop count is hardcoded, i see |
||
|
||
let R0: Point<bigint> = [0n, 1n] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see there's a unit test covering multiply by zero, which is good to confirm this still behaves the same way as before without the special-case. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like that. It is done. |
||
let R1: Point<bigint> = base | ||
|
||
// 'order' is a number of 254 bits, such as 1n<<253n. Therefore, we initialize the mask as 1<<253 | ||
for (let mask = 1n << 253n; mask > 0; mask >>= 1n) { | ||
if (e & mask) { | ||
R0 = addPoint(R0, R1) | ||
R1 = addPoint(R1, R1) | ||
} else { | ||
R1 = addPoint(R0, R1) | ||
R0 = addPoint(R0, R0) | ||
} | ||
|
||
exp = addPoint(exp, exp) | ||
rem = scalar.shiftRight(rem, BigInt(1)) | ||
} | ||
|
||
return res | ||
return R0 | ||
} | ||
|
||
/** | ||
|
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 suggest additionally referring to the named algorithm being used here (Montgomery Ladder) perhaps with a link to a description of the algorithm (Wikipedia or some other source).
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! Will do.