andy lawrence <[email protected]> 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

-- 
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

Reply via email to