Side-channel leakage in the mpz_powm_sec interface

[Niels Möller]

marco.bodrato at tutanota.com writes:

>> 1. Document that the mpz_t result from mpz_powm_sec always has an alloc
>> size >= n, where n is the limb size of the modulo input, and that the
>> limb array is zero padded up to n.
>>
>
> You write ">= n" and not "=n" because if it was larger we avoid to re-allocate it, right?

Yep.

> The application does not really need to "take advantage of" the fact
> that allocated space may be larger than the strictly-needed space,
> should it?

I was thinking that the typical next step would be converting to an
octet string, and to avoid leakage, it has to do that via some method
that ignores the size field and instead uses n (the size of the modulo).
Which works only assuming the new behavior.

Hmm, but for the use case of an RSA secret key operation, the next step
would be CRT reconstruction (since it's a standard performance
optimization to do powm separately for the two secret vectors p and q).
And then maybe unblinding. And then all of those operations must be done
using mpn functions and size n, not mpz.

So I'm leaning towards documenting this problem with mpz_powm_sec, and
recommending mpn_sec_powm for applications that need side-channel silence.

> A possible implementation of your 2-3 points (I didn't look at
> documentation) could be the following.

Looks rather neat! But I'm still not quite convinced that it is worth
doing.

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.