# RSA-OAEP Input Parameters

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.

-
See PKCS#1v2.1 which calls that a Label, and states it might be empty, or in some specified syntax. See here, in particular Remark 3, for a discussion on possible uses. –  fgrieu Mar 11 '12 at 19:52
@fgieu That might be considered an answer. Answered questions will receive less attention from other experts (and nutcases such as me :) ). –  Maarten Bodewes Mar 21 '12 at 0:53
@owlstead: Feel free to expand this into an answer. –  Paŭlo Ebermann Apr 15 '12 at 21:20

## 1 Answer

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 (..)

-