On 04/14/2012 09:28 AM, Niels Möller wrote:
/* RSA signatures, using PKCS#1 1.5
- Input should be a BER encoded DigestInfo
*/ int rsa_digest_info_sign(const struct rsa_private_key *key, unsigned length, const uint8_t *digest_info, mpz_t signature);
int rsa_digest_info_verify(const struct rsa_public_key *key, unsigned length, const uint8_t *digest_info, const mpz_t signature);
That seems reasonable (if and how the implementation of nettle's other rsa sign/verify functions could be reorganized to make use of that, I'm not sure). Minor points: It should really be DER encoded, right?
PKCS #1 1.5 says BER and there were quite some implementations that used BER for encoding instead of DER.
And I guess you'd also want a _sign_tr variant.
Indeed. I only listed the basic interface for review.
As for naming, maybe I'd want to have
"pkcs1" int he name, not sure.
I wanted to use PKCS1 but it might be misleading as PKCS #1 1.5 has a different padding method than PKCS #1 2.1 which uses OAEP. I don't know if rsa_pkcs1_1_5_sign is reasonable...
A question for all of you: Nettle currently has two flavors of sign functions for each algorithm. E.g., int rsa_sha1_sign(const struct rsa_private_key *key, struct sha1_ctx *hash, mpz_t signature);
int rsa_sha1_sign_digest(const struct rsa_private_key *key, const uint8_t *digest, mpz_t s); The former could be implemented in terms of the latter (currently it's not, to avoid an unnecessary copy, which may be a pointless optimization in this context).
The point of the first function is convenience, where you can create a
signature simply by
sha1_init sha1_update rsa_sha1_sign without bothering with allocating and writing the actual digest. Do you think this design makes sense?
IMO it makes sense, but I think the drawbacks, which are maintaining one extra function per hash, do not really outweigh the benefit which is not really noticeable in the RSA operation.
regards, Nikos