search

square / jna-gmp

A Java JNA wrapper around the GNU Multiple Precision Arithmetic Library.
Apache License 2.0
62 stars 24 forks source link

Consider having GmpInteger override certain BigInteger methods #12

Open dragonsinth opened 8 years ago

dragonsinth commented 8 years ago

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 commented 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.

thhofer commented 7 years ago

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 commented 7 years ago

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?