1

I want to calculate ($m^{e} \pmod{N}$) in C or C++. I want to use 2048 bits long modulus $N$ and thus the above process of exponentiation will use a huge amount of calculations and time. I want to know the possible optimizations I can use.

I particularly came across this :

Converting the exponent to its binary bit pattern and then looping from MSB to LSB, calculating the square of the result at each step mod N and if the present bit of exponent is 1, multiplying the result by m.

Also, I can compute the square of the result using the Karatsuba algorithm.

What other optimizations, if possible, exists in this regard?

Is there any already implemented and optimized library for C or C++ for such type of modular arithmetic?

  • @SqueamishOssifrage Agreed!! Changed the title. RSA was really irrelevant to this question. – Madhuchhanda Mandal Nov 12 '19 at 20:24
  • A reasonable cheap constant-time approach is fixed-window exponentiation with Montgomery multiplication, with table lookup by arithmetic. Faster—but leakier—approaches involve sliding windows. A standard reference for these can be found in Menezes, van Oorschot, and Vanstone's _Handbook of Applied Cryptography. For modern implementation with side channel defenses, consider reviewing what BearSSL does. – Squeamish Ossifrage Nov 12 '19 at 20:25
  • If you know the factors of $N$, then you can also use the Chinese remainder theorem, so it matters whether you're talking about the public-key operation or the private-key operation. For the public-key operation, you just can pick $e = 3$ so it's a single squaring plus a single multiplication, as long as you use the primitive in a serious cryptosystem like RSA-KEM or RSA-PSS (and not ‘textbook RSA’). – Squeamish Ossifrage Nov 12 '19 at 20:26
  • 1
    "Is there already a library to do this" - "yes, BearSSL / BoringSSL and their leakier competitors" which is strictly speaking a request for a software recommendation and thus off-topic. Asking for efficient, naturally side-channel resistant algorithms on the other hand is perfectly on-topic. – SEJPM Nov 12 '19 at 20:27
  • @kelalaka FYI, mpz_* is a bad idea for cryptography because gmp automatically truncates mpz objects according to their most significant bit, which leaks the position of the most significant bit by timing, which is a popular attack vector these days: https://minerva.crocs.fi.muni.cz, http://tpm.fail. You should use mpn_* instead. (Why gmp even provides mpz_powm_sec is a mystery to me.) – Squeamish Ossifrage Nov 12 '19 at 20:30
  • @SqueamishOssifrage Here they say that mpz_powm_sec function, supported by a corresponding mpn_sec_powm and mpn_cnd_sub_n – kelalaka Nov 12 '19 at 20:37
  • It looks like these days, OpenSSL, gmp, and BearSSL all use essentially what I described: fixed-window exponentiation with Montgomery multiplication. – Squeamish Ossifrage Nov 12 '19 at 20:37
  • 1
    @kelalaka Yes, I know, but mpz_powm_sec still has the msb side channel. You shouldn't use mpz_* at all for secrets. – Squeamish Ossifrage Nov 12 '19 at 20:38
  • @SqueamishOssifrage I suppose if you wanted to try hard enough you could probably also use addition chain exponentiation (14.98 in the handbook of applied crypto) and use 3-4 primes for RSA with the carmichael instead of the euler-phi function. – SEJPM Nov 12 '19 at 20:41
  • @SqueamishOssifrage Thanks a lot! It will be used in the Private key operations so the exponents are going to be large. I will have a look at the Handbook of Applied Cryptography. – Madhuchhanda Mandal Nov 12 '19 at 20:41

0 Answers0