In recent months, some new RSA functions have been added, from suggestions and work of Nikos. I'd like to hear comments on the interface before release.
Timing resistant decryption function, using RSA blinding:
int rsa_decrypt_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func *random, unsigned *length, uint8_t *message, const mpz_t gibberish);
New signing functions taking a "DigestInfo" as input:
int rsa_pkcs1_sign(const struct rsa_private_key *key, unsigned length, const uint8_t *digest_info, mpz_t s);
int rsa_pkcs1_verify(const struct rsa_public_key *key, unsigned length, const uint8_t *digest_info, const mpz_t signature);
Timing-resistant version of the signing function:
int rsa_pkcs1_sign_tr(const struct rsa_public_key *pub, const struct rsa_private_key *key, void *random_ctx, nettle_random_func random, unsigned length, const uint8_t *digest_info, mpz_t s);
The _tr fucntions use these internal functions for RSA blinding:
void _rsa_blind (const struct rsa_public_key *pub, void *random_ctx, nettle_random_func random, mpz_t c, mpz_t ri); void _rsa_unblind (const struct rsa_public_key *pub, mpz_t c, const mpz_t ri);
Do you think this looks good? I see that there's some inconsistency of using "nettle_random_func random" vs "nettle_random_func *random", the latter variant is the preferred form.
It would be nice with timing resistant versions of the other signing functions, byt I hesitate since we would end up with such a large number of functions. Some redesign (for some later version) may be appropriate.
It's possible to do deterministic RSA blinding, using something like HMAC(encoding of private key, message) to generate the random number. And in similar way, one can do deterministic DSA signatures. That's also for later, but you may want to take that possibility into account when commenting on the interface.
In somewhat related reorganization, the interface of the internal function pkcs1_signature_prefix has changed and is not compatible with the old version. Questions:
1. Is anyone depending on that function?
2. Does a change of this function require a new solib number? (Depends on the answer to previous question).
3. Should I rename it to _pkcs1_signature_prefix, in order to (i) make it more clear it's an internal function, and (ii) make applications depending on the old behaviour break in a more predictable fashion?
Regards, /Niels
On 06/19/2012 10:34 PM, Niels Möller wrote:
In recent months, some new RSA functions have been added, from suggestions and work of Nikos. I'd like to hear comments on the interface before release.
Do you think this looks good? I see that there's some inconsistency of using "nettle_random_func random" vs "nettle_random_func *random", the latter variant is the preferred form.
If this is because of me, feel free to correct it. It must have been a typo.
- Should I rename it to _pkcs1_signature_prefix, in order to (i) make it more clear it's an internal function, and (ii) make applications depending on the old behaviour break in a more predictable fashion?
I'd say this is a good option. If you care about backwards compatibility then the old function could also be present.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
I see that there's some inconsistency of using "nettle_random_func random" vs "nettle_random_func *random", the latter variant is the preferred form.
If this is because of me, feel free to correct it. It must have been a typo.
I don't think you introduced that. I changed the typedef from
typedef void (*nettle_random_func)(void *ctx, unsigned length, uint8_t *dst);
to
typedef void nettle_random_func(void *ctx, unsigned length, uint8_t *dst);
some versions ago (and similarly for other typedefs for function type). And I tried to update all uses at the time, but I'm afraid I didn't get them all (rsa_encrypt, rsa_generate_keypair). And then we got it wrong for the recent rsa_decrypt_tr. So I'll fix them as I find them. Technically, that may be an API change, but I think it's very unlikely to cause any problems.
- Should I rename it to _pkcs1_signature_prefix, in order to (i) make it more clear it's an internal function, and (ii) make applications depending on the old behaviour break in a more predictable fashion?
I'd say this is a good option. If you care about backwards compatibility then the old function could also be present.
The possibility of keeping the old one hadn't occured to me, but that's a good suggestion. It's easy to do, and nice to users. Maybe I should also read up on how to tell gcc that it is considered both internal and obsolete.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se