Nikos Mavrogiannopoulos <[email protected]> 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
