andy lawrence ajlawrence@acm.org writes:
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.
Start with the _tr version then.
RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC }
Is this for a signature on arbitrary data, or in the context of x.509? If a signature is always packed up in some asn.1 structure, we should perhaps use that representation in the interface, instead of a plain mpz_t.
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.
But at least the hashAlgorithm above is required to be the same as inside the digestInfo?
I had envisaged the one currently specified in the function definition being used for the MGF.
Make sense to me, until there's some actual use of different MGF.
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?
Try to write the helper functions needed to make each of the hash-specific functions small and trivial. One could even define some shared macro to expand to the function definition, but that's probably not worth the effort.
Regards, /Niels