Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Although the HMAC avoids the need for randomness, you need to get a key somehow, so the gain might not be much.
The idea is to reuse (hash of) the private RSA key as the HMAC key. And similarly for deterministic DSA.
What about the rsa_compute_root? This is the only function I can use from nettle for RSA signatures
I wasn't aware of that. That's an argument for an rsa_compute_root_tr (or alternatively, public rsa_blind and rsa_unblind helpers).
Can you explain briefly what special signatures are used by tls? (It was more then 10 years since I wrote an implementation, then it was ssl version 3).
If there was an rsa_pkcs1_sign() and rsa_pkcs1_verify() with similar interface to encrypt/decrypt, I could use those instead.
Can you propose such an interface? Currently, rsa_md5_sign calls pkcs1_rsa_md5_encode followed by rsa_compute_root. If it's easy for you to use rsa_compute_root in the same way, then I guess there's no need to introduce new low-level primitives, but maybe it could be rearranged in some better way?
Or, since tls is an important application, it may make sense to directly add tls-style signatures to Nettle.
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.
I see. It would really be helpful with some tools for measuring the input dependence in the timing of rsa_compute_root. GMP's mpz_powm may well behave quite differently from openssl's.
Regards, /Niels