I was looking for a security project to work on and saw that
implementing RSA-PSS in was listed on the GNUTLS website.
I will attempt to make the argument order consistent.
Yes the salt is supposed to be randomly generated by the signing
application. I will modify the function definition to include a
randomness source as you have suggested.
I agree in that it will be less work to only implement the _tr
versions of rsa-pss. I do not know what the consumers of Nettle want
so this decision is better taken by you. There may be some reason to
use the older version.
The verifier has to know the salt length in order to recover the salt
and verify the signature. It is usually packaged together with the
signature in the algorithm parameters:
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm [0] HashAlgorithm DEFAULT sha1,
maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,
saltLength [2] INTEGER DEFAULT 20,
trailerField [3] TrailerField DEFAULT trailerFieldBC
}
As seen in the above parameters, it should be possible to choose both
the hash algorithm for the message and the hash algorithm for the mask
generation function. I had envisaged the one currently specified in
the function definition being used for the MGF. The choice of this
hash function is independent of the one used to hash the message. I
was planning on following the convention with the existing RSA code
and supplying a pile of different functions, one for each hash
algorithm. Do you have a suggestion on how to prevent this repetition?
Best wishes,
Andrew Lawrence
On Wed, Dec 2, 2015 at 8:33 PM, Niels Möller <[email protected]> wrote:
> 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
