johngray-dev
commented
2 months ago Thanks for the comments. We added PSS salt parameters. We used 256 bits for id-MLDSA44-RSA2048-PSS-SHA256 and 512 bits for id-MLDSA65-RSA3072-PSS-SHA512
https://github.com/lamps-wg/draft-composite-sigs/commit/5753715bfe3cf35b5f797b14d8584041459a3266
The suggested PSS parameter tables for id-MLDSA44-RSA2048-PSS-SHA256 and id-MLDSA65-RSA3072-PSS-SHA512 don't give any indication of the salt length to use.
In my implementation we used 64-bytes for both, but RFC's 4055 and 8017 suggest the typical salt length as one that matches the hashing length. This would indicate a "typical" salt length of 32 for id-MLDSA44-RSA2048-PSS-SHA256 and 64 id-MLDSA65-RSA3072-PSS-SHA512
RFC 8017 section 9.1 says this:
Typical salt lengths in octets are hLen (the length of the output of the hash function Hash) and 0. In both cases, the security of RSASSA-PSS can be closely related to the hardness of inverting RSAVP1.
From Tim Holobeek:
Hello,
Our engineering team has been looking at composite signatures, and found a potential ambiguity. The draft uses OIDs for everything, with no parameters (good), but this begs the question of what the right parameters are for rsa-pss, in particular the salt length, which isn’t included in the parameters table.
There’s also the question of what the right answer is, which honestly I haven’t had time to review. They’re saying that RFC 4055 suggests matching the length of the hash in its security considerations section, which sounds reasonable, but Openssl seems to be hard-coded to always use 64 bytes of salt. Which sounds right to me for SHA512 but not necessarily SHA256.