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