When creating padding for RSA using OAEP, a message is prepared as follows:

Hash(Input Parameter) || Zeros || 1 || Message

My question is, what should the Input Parameter be? It must be known to both sides, I understand it can be an empty array (string, whatever). In that case there is no need to calculate the hash, hashing an empty input always produces the same result.

Is there a recommendation regarding what to use as the input parameter?

I'm thinking about hashing the public modulus n, which is already known by all parties. It's not necessary I suppose since the random seed from the other part of the OAEP procedure will change the final value anyway, but I'm still curious what is considered "best practice", or some requirement that I missed.

1 Answer
1

The Input Parameter in the question is called a Label in PKCS#1v2.1; this standard states it might be empty, or be expressed in some specified syntax. I borrow Victor Shoup's explanation from Remark 3 in this paper:

A label is a byte string that is effectively bound to the ciphertext
in a nonmalleable way. It may contain data that is implicit from
context and need not be encrypted, but that should nevertheless be
bound to the ciphertext. We view a label to be a byte string that is
meaningful to the application using the encryption scheme, and that is
independent of the implementation of the encryption scheme. For
example, there are key exchange protocols in which one party, say A,
encrypts a session key K under the public key of the other party,
say B. In order for the protocol to be secure, party A's identity
(or public key or certificate) must be non-malleably bound to the
ciphertext. One way to do this is simply to append this identity to
the cleartext. However, this creates an unnecessarily large
ciphertext, since A's identity is typically already known to B in
the context of such a protocol. A good implementation of the labeling
mechanism achieves the same effect, without increasing the size of the
ciphertext. Labels may also be of arbitrary and variable length, but
we do not impose the restriction that the encryption and decryption
algorithms should be able to process labels as streams. Both the ECIES
and RSA-OAEP submissions include the notion of a label (where it is
called an encoding parameter), although absolutely no indication was
given as to the role or function of a label. Nevertheless, it seems to
be a potentially useful feature (..)