The central part of the RSASSA-PSS signature scheme of PKCS#1 is the EMSA-PSS encoding operation, described in section 9.1 of the standard.

This encoding method makes use of a padding (titled Padding1) which is simply eight zero-bytes (0x00). The concatenation of this padding, the hash of the message and the randomly chosen salt is then hashed once more, forming one part of the final signature - see eg the ASCII diagram on page 39.

Which brings me to my question - what is the purpose of this padding specifically?

The one effect I could think of is that it ensures that - given an empty salt and an empty message - the input to the hash function will not be empty. However this seems dubious as all hash functions I am aware of will work just fine with empty inputs, and the hash - be it of an empty byte string or a byte string containing 8 * 0x00 - will be deterministic in either case.

The purpose of the second padding - Padding2 - is clear to me, as it ensures that the signature has the desired (user-defined) length, while simultaneously being structured such that the salt can be retrieved without requiring prior knowledge of its length.


1 Answer 1


I conjecture that this salt is essentially a version number for future extensions, tasked with ensuring that signature per another version using a different salt is not a valid signature for the version described.

I can imagine two other roles:

  • It makes it even less likely that an RSASSA-PSS signature comes to match an RSA-PSS signature of something pre-existing starting with a hash (but there's also the 0xBC for right padding of EM playing that role). Recall that RSA-PSS was introducted by Mihir Bellare and Phillip Rogaway's The Exact Security of Digital Signatures - How to Sign with RSA and Rabin, in proceedings of EuroCrypt 1996; and it's reduction to practice RSASSA-PSS is a slight variation, as explained in notes of section 9.1 of PKCS#1v2.2.
  • It makes it less untrue that the hash function / random oracle producing $M'$ is independent from the one producing $\text{mHash}$ and the one used inside MFG1, which arguably is a silent assumption in the security argument.
  • $\begingroup$ Apologies for the late response. If I understood your main point correctly, then this serves as a 'version number' insofar as - while it obviously cannot be recovered from the signature - it provides a way to make sure that the same message signed twice, with the same salt but different (future) versions of the standard, will provide different signatures? Your second point about differentiating the RSASSA-PSS scheme from another potential RSA-PSS-based signature scheme seems sensible as well. :) $\endgroup$
    – Morrolan
    Commented Oct 20, 2020 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.