Use BN reduction context in modexp precompile

[s1na]

This PR attempts to fix #214. I tried to use BN.mont explicitly, but got some weird result:

new BN(1).toRed(BN.mont(new BN('64', 16))).fromRed() which I thought should return 0x1, actually returns 0x18! Not sure if this is a bug or intended?

Should I do benchmarks to make sure this is actually more performant?

Update: It's running out of heap memory on modexp_37120_37111_1_1000000

[coveralls]

Coverage remained the same at 94.657% when pulling e70d0c0 on modexp-reduct into 9b1b24a on master.

[axic]

Use .lten?

[axic]

Should I do benchmarks to make sure this is actually more performant?

If you could that would be interesting to see.

[cdetrio]

new BN(1).toRed(BN.mont(new BN('64', 16))).fromRed() which I thought should return 0x1, actually returns 0x18! Not sure if this is a bug or intended?

I read here that if r is a power of 2, then the modulus n needs to be odd and greater than 3. Looking at lib/bn.js#L3408, r is being calculated as a power of 2 that's greater than n. If you pass any odd number > 1 to BN.mont(), then your line returns what you expect (it also seems to work with 3). Maybe bn.js should warn if mont() is called with an even number.

[s1na]

Thanks @cdetrio, that seems to be it.

To get an initial idea of how they compare, I ran the state tests on master and this branch, and measured the time it took to execute the expmod(B, E, M) line in the precompile in both branches. The tests were only run once. It's very inaccurate probably, but there doesn't seem to be much difference in execution times. Here are the measurements.

[holgerd77]

Rebased this.

[holgerd77]

Looks good.