rsa blinding patch

[Niels Möller]

Nikos Mavrogiannopoulos <nmav at 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

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.