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