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
_______________________________________________
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs
