Andrey Andrey - 3 months ago 15
Java Question

How to properly use Bouncy Castle's OAEPEncoding for RSA (Lightweight API)

I've been playing around with Bouncy Castle's implementation of RSA (Lightweight API) and got the basics figured out. Looking at their spec for JCE provider implementation I noticed that different padding schemes can be used with RSA. From what I understand, by default null padding is used. So I began exploring OAEP padding, particularly

OAEPWithSHA512AndMGF1Padding
. Searching with Google wasn't very helpful so I began digging through BC's source code and found
org.bouncycastle.jce.provider.JCERSACipher
class. But looking at
initFromSpec
quickly gave me a headache... Specifically, I don't understand what the last two parameters that can be passed to the
OAEPEncoding
constructor are. According to BC's API the
OAEPEncoding
constructor that allows four parameters accepts
Digest mgf1Hash
and
byte[] encodingParams
as the last two arguments. This stumped me because I have no idea how to get a hold of an instance of the mask generation algorithm nor do I understand the purpose behind the byte array referred to as
encodingParams
. What should be the values of
arg3
and
arg4
in the code below?

RSABlindedEngine rsa = new RSABlindedEngine();
SHA512Diges sha512 = new SHA512Digest();
Digest arg3 = ???;
byte[] arg4 = ???;
AsymmetricBlockCipher cipher = new OAEPEncoding(rsa, sha512, arg3, arg4);

Answer

OAEP is specified by PKCS#1, section 7.1.

OAEP requires the following parameters:

  • a hash function;
  • a "mask generation function" which can be thought of as a hash function with unlimited output length;
  • a "label" (an arbitrary sequence of bytes).

There is only one defined mask generation function, called MGF1, and that function is built over a hash function. So your arg3 is the hash function which MGF1 will use. It may be the same hash function than the first one (I am not sure it may be the same Digest instance in the Bouncy Castle API; I am talking mathematically here). It may also be another hash function.

The label can be used as a kind of distinguishers between instances (e.g. you could encrypt data with an explicit "purpose" encoded in the label). It is handy in some mathematical proofs, but right now PKCS#1 recommends using an empty string and be done with it. For the purposes described in PKCS#1, an empty label is as good as any.

The decryption process must know those parameters to operate. It is customary to encode them in the structure which comes along with the encrypted message and says "this is encrypted with RSA/OAEP"; that's how it happens in CMS.

When in doubt, use the same hash function as first parameter and for MGF1, and use an empty label.