Commits on Aug 26, 2024

1. Fix bugs in bn.halveM and bn.montpowermod …

   `montpowermod` was incorrectly assuming that the base value was already
   modulo N. This went undetected for so long because the `montMul`
   function is VERY robust against unusually-large bases. As long as the
   base was within ~8 bits of the modulus, the algorithm would perform
   correctly. It was also partly masked by the second issue in halveM.
   
   The halveM function did not handle halving 0 or 1 correctly. It would
   pop the last limb from the array, returning a `bn` in a weird state.
   Most other `bn` operations could recover from it, but the check that
   `montpowermod` performs on the modulus is particularly sensitive to
   the bug. On my machine this issue was related to the montpowermod,
   so I have included both bugs together in the same commit. See below.
   
   I suspect that there is another issue in the montpowermod code, it
   doesn't call `normalize()` after `RP.add(NN)` and `NP.add(RR)`, while
   the `halveM()` call assumes its input is normalized. I haven't actually
   encountered erroneous output, though.
   
   ------
   
   On the windows build node v20.10.0, the jit version of halveM was
   behaving differently from the interpreted version (i.e. while step
   debugging, and while the jit was cold), for the specific
   input `new bn(2000).powermod(800, 19)`, evaluating halveM on line:
   
   ```js
   while (RT.greaterEquals(1)) {
         RT.halveM();
   ```
   
   This would cause the extended Euclidean algorithm check to fail
   reverting to the slower (correct) powermod code.
   
   Powermod bug was introduced in commit 2f591b4
   
   HalveM bug was introduced in commit c08108f
   
   Closes bitwiseshiftleft#419

   

   Phlosioneer committed Aug 26, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for b894976
   • Browse repository at this point

   Copy the full SHA

   b894976 View commit details

   Browse the repository at this point in the history