Wow! Impressive how fast you did this!
Thanks, but it is mostly the fact that the bouncy castle library has an EC point library built in.
Also, the formula just "worked". I had expected an hour or two of debugging at least.
- I suppose that addition can be sped up in bounty castle because parameter 'A' is zero for the BC curve.
Dunno. It looks like addition doesn't actually depend on the curve parameters, weirdly.
- This part of your code is interesting:
for (int j = 255; j >= 0; j--) {
sum = sum.twice();
for (int i = 0; i < len; i++) {
if (u2.testBit(j)) {
sum = sum.add(Q);
}
}
}
I do not know how much the 'if' and the 'testbit' method cost, but theoretically they could be replaced by a symbolic expression evaluator, at the cost of traversing a tree and a few pointers. Not sure what would be fastest.
Java doesn't really do pointers like that. However, I think the EC calcs are probably the limiting factor, so that shouldn't matter.
Test bit is probably implemented as an array lookup + bit mask.
- I am unsure whether the 'attack' on batch verifications apply to the use of signature verifications of the blockchain in the BC context. Presumably, one could apply batch verify until, say, the last 1000 blocks, then switch to the individual verifications.
Dunno. There is a paper that talks about protecting it by using random numbers.
You multiply u1(i) and u2(i) by a constant. It means you have to multiply R(i) by the same constant though, so that means the LHS has more calcs too.