Daiki Ueno ueno@gnu.org writes:
I'd suggest
VALGRIND_MAKE_MEM_DEFINED(m, sizeof(*m)); VALGRIND_MAKE_MEM_DEFINED(m->_mp_d, sizeof(mp_limb_t) * mpz_size(m));
The first is a bit tricky since the mpz_t is a typedef:ed array, I hope I got it right.
Fixed, thanks for pointing that out.
I've tried to actually enable use of this function, by replacing pss_encode_mgf1 by pss_encode_mgf1_for_test below in the pss-test.c file. Turns out it's not truly side-channel silent with respect to the salt and digest inputs. The problem is that the initial bytes of the padded value, em, depend on both digest and salt.
When converting em to an mpz_t, gmp wants internal normalization, so it has to check if the high bits of the number are zero or not, resulting in a branch depending on the input values.
The valgrind failure looks like this:
==23591== Memcheck, a memory error detector ==23591== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==23591== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info ==23591== Command: ./pss-test ==23591== ==23591== Conditional jump or move depends on uninitialised value(s) ==23591== at 0x52C1D01: __gmpz_import (in /usr/lib/x86_64-linux-gnu/libgmp.so.10.2.0) ==23591== by 0x4E414C9: nettle_mpz_set_str_256_u (bignum.c:146) ==23591== by 0x4E42973: nettle_pss_encode_mgf1 (pss.c:124) ==23591== by 0x10B16B: pss_encode_mgf1_for_test.constprop.0 (pss-test.c:28) ==23591== by 0x10B32B: test_main (pss-test.c:51) ==23591== by 0x10AF6E: main (testutils.c:134)
It's curious that pkcs#1 v1.5 signatures don't have this particular issue, since v1.5 padding always puts the most significant 1 bit at the same position.
So I guess we'll unfortunately have to take out the valgrind magic from this test. It's still desirable to test if RSA private key operations are side-channel silent with respect to the private key.
If/when nettle's RSA code is reorganized to use the mpn interface for signatures rather than the mpz interface, normalization would be less of an issue, since most mpn functions tolerate leading zeros.
Regards, /Niels