Open dragonsinth opened 8 years ago
We could actually have GmpInteger override modPow() but just call super.modPow(), and leave a comment as to why it's not actually the native implementation. Or else we could use the native implementation on positive exponent, and the non-native on negative exponent.
Now that the library does support negative exponents, should we consider including modPow in the methods that could be overridden? Or are there other subtle behavioral differences?
So the interesting thing with modPow is, generally it's the exponent and modulus that you reuse over and over (in crypto), and the base (the message) that changes a lot. This suggest to me that simply overriding the base method with same-signature e.g. modPow(BigInteger exponent, BigInteger m)
won't necessarily drive the most optimal code paths. Maybe it would make more sense to introduce a different signature method, e.g. modPow(GmpInteger exponent, GmpInteger m)
to drive home the idea that it's the exponent and modulus that you really want to reuse across invocations?
For modPow, we did not override BigInteger due to subtle behavioral differences; for example BigInteger.mowPow() supports negative exponents, whereas our GmpInteger does not.
However, for things like modInverse(), it might be a reasonable straight up replacement.