Side-channel leakage in the mpz_powm_sec interface

Hubert Kario hkario at
Thu Aug 24 18:39:04 CEST 2023


While I was researching CVE-2022-4304 in OpenSSL, I looked into some other
implementations (specifically to see if there are constant-time 
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 
This is despite the documentation stating that "This function is intended 
cryptographic purposes, where resilience to side-channel attacks is 

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 

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

1 -
2 -
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

More information about the gmp-bugs mailing list