Hubert Kario <hka...@redhat.com> writes: > 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).
And that's for all inputs? Nice. (I think an earlier version used a potentially leaking table lookup on the lowest few modulo bits, as the first step in computing a partial inverse. Which is probably benign in most use-cases, but still undesirable for a function claimed to be side-channel silent). > 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. Is the main problem the normalization of the *output* of mpz_powm_sec? For this class of attacks, my understanding is that the secret exponents are fixed (when doing repeated operations on the secret key under attack), while the modulo is public, and the base is under the control of the attacker and hence already known to them. > 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? It's preferable to use the mpn_powm_sec. When using mpz_t, I see no reasonable to avoid leakage of the normalized size (or number of all-zero limbs at the most significant end). Regarding Nettle (which uses GMP, and is used by GnuTLS): The RSA code dates from the 1990s (it's one of the oldest algorithms in Nettle), and has seen a series of incremental improvements over the years, but aiming to not break api compatibility more than necessary. Most recently side-channel-silent "decoding" in pkcs#1 RAS decryption. The current interface is more complex than I'd like, with several variants of most private key operations, which is a bit confusing. It would be desirable to with a larger rework; it would be better to (i) use byte strings, rather than mpz_t values, for the interface to applications, and (ii) use only mpn-level GMP functions internally. And I would recommend the same approach for any other implementation of RSA on top of GMP. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs
