andy lawrence ajlawrence@acm.org writes:
I have been thinking about implementing RSASSA-PSS in Nettle.
Thanks. As I said earlier, I haven't looked at PSS for a long time, so please excuse my ignorance. I would also like to ask if we have any list members who are more familiar with it and willing to help with code review? (Otherwise, I'll just have to read up on it, of course).
Are there any particular application or protocol you have in mind which needs pss?
+/* PSS style signatures */ +int +rsa_pss_sign(const struct rsa_private_key *key,
size_t length, const uint8_t *digest_info,mpz_t s, const struct nettle_hash *hash_func,size_t salt_length, const uint8_t *salt);
Try as far as possible to be consistent with the argument order in the pkcs1 functions. I think length, digest_info and signature should be the final three arguments (for all three functions). There are no simple rules here, but I tend to put constant things like the hash algorithm early, and per-message data, like the salt, later.
What's the salt? If it's supposed to be randomly generated by the signing application, I think it's better to pass in a randomness source to the signature function (similarly to dsa and ecdsa, and the _tr RSA functions).
We're also in a process to promote the _tr functions and deprecate the older ones. Maybe we should do *only* the _tr version for the new pss code?
+int +rsa_pss_verify(const struct rsa_public_key *key,
size_t length, const uint8_t *digest_info,const mpz_t signature, const struct nettle_hash *hash_func,size_t salt_length);
It looks like the salt_length is an algorithm parameter; the verifier has to know it to be able to verify a signature? Is it usually packaged together with the signature, or is it agreed upon in advance?
And speaking of parameters, is the hash function above required to be the same as the one encoded into the asn.1 digest_info and used to hash the message? If so, maybe we shouldn't make the interface flexible enough to allow different hash functions?
Regards, /Niels