On 04/09/2012 04:29 PM, Niels Möller wrote:
> One way may be to *always* do blinding. But I hesitate before requiring > the user to setup and provide a randomness function. I note that the > document you pointed to, ftp://ftp.rsasecurity.com/pub/pdfs/bull-2.pdf, > suggests using something similar to HMAC(private-key, input) to generate > the random number to be used for blidning. Doing that (and maybe have an > *optional* randomness source) could make sense. Although the HMAC avoids the need for randomness, you need to get a key somehow, so the gain might not be much. > The needed randomness info has to go either as argument to all private > key operations, or be put somewhere in the private key struct. And > either way makes things more complicated. Indeed. > I think it makes some sense to implement rsa_decrypt_tr now, with no > advertised internals, and give the signature interface more time. What about the rsa_compute_root? This is the only function I can use from nettle for RSA signatures (TLS is peculiar on its signatures thus the exported interface isn't sufficient). If there was an rsa_pkcs1_sign() and rsa_pkcs1_verify() with similar interface to encrypt/decrypt, I could use those instead. > BTW, do you have any test cases? It would be useful both to have test > cases that check that the _tr operations give the correct result (that > should ba a simple addition to testsuite/rsa-encrypt-test, I guess), and > some way to quantitatively check how the timing depends on the inputs, > for both rsa_compute_root and rsa_compute_root_tr. I had modified the rsa-encrypt-test.c to include a test for the timing resistant version as well. Other than that I have no other test cases. regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
