PKCS#1: Purpose of `Padding1` in EMSA-PSS encoding method

Question

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.

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.