8
$\begingroup$

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.

$\endgroup$
3
  • 4
    $\begingroup$ 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. $\endgroup$
    – fgrieu
    Mar 11, 2012 at 19:52
  • $\begingroup$ @fgieu That might be considered an answer. Answered questions will receive less attention from other experts (and nutcases such as me :) ). $\endgroup$
    – Maarten Bodewes
    Mar 21, 2012 at 0:53
  • $\begingroup$ @owlstead: Feel free to expand this into an answer. $\endgroup$ Apr 15, 2012 at 21:20

1 Answer 1

8
$\begingroup$

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

$\endgroup$

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.