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