Side-channel leakage in the mpz_powm_sec interface

[Hubert Kario]

Hello,

While I was researching CVE-2022-4304 in OpenSSL, I looked into some other
implementations (specifically to see if there are constant-time 
implementations
of modular arithmetic).

I was able to confirm that the low-level functions, like the mpn_sec_powm()
function have no timing leakage with regards to operands or result
(exactly like section 8.1 of the manual[2] states).
I wasn't able to do the same with regards to the mpz_powm_sec() function.

Irrespective of how I initialised the used mpz_t objects, if the operands
don't have high order words set, the timing of the operation is different.
Thus I believe that if mpz_powm_sec() is used for RSA or Diffie-Hellman
it would be vulnerable to the Bleichenbacher or Raccoon attacks 
respectively.
This is despite the documentation stating that "This function is intended 
for
cryptographic purposes, where resilience to side-channel attacks is 
desired."[1]

I think this is likely caused by exactly the same issue as in OpenSSL: that
the mpz objects are "clamped" or "normalised", where the methods make sure
that the returned object doesn't use more memory than necessary to store 
the
number.

Did I miss the methods to ensure that the objects are not clamped, or 
should
the mpz_powm_sec() interface be marked as _not_ secure for cryptographic
purposes?

1 - 
https://gmplib.org/manual/Integer-Exponentiation#index-mpz_005fpowm_005fsec
2 - https://gmplib.org/manual/Low_002dlevel-Functions
-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic