On 04/07/2012 10:47 AM, Niels Möller wrote:
I'm not sure if the low-level rsa_compute_root should be aware of the blinding, or if it should be the responsibility of its callers (using _rsa_blind, _rsa_unblind helper functions, put in rsa_blind.c or so).
Support for blinding is desirable not only for rsa_decrypt, but also for the various rsa_*_sign functions, right?
The blinding function should probably use nettle_mpz_random, which
provides for *almost* uniform distribution mod n by generating a few
extra bits before the mpz_fdiv_r.
I've updated the patch to account for that and other issues. http://homes.esat.kuleuven.be/~nikos/0001-Added-timing-resistant-versions-of...
What I haven't done is to duplicate all the rsa_(hash)_sign functions. They are quite many and it doesn't make much sense duplicating all of them. Do you have any suggestion on compacting it?
As for interface, I have been considering to also add some kind of deterministic dsa signatures, substituting something like HMAC(private key, message) for the random input, and if possible, it would be nice to have a consistent interface for {rsa, dsa} signatures {with, without} randomness input.
I don't really think that the random number in DSA relates to RSA blinding. The random number in DSA is part of the signature scheme, while the RSA blinding random number is just to prevent timing attacks.
regards, Nikos