Consider having GmpInteger override certain BigInteger methods

[dragonsinth]

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.

[dragonsinth]

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.

[thhofer]

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?

[dragonsinth]

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?