Skip to content
Advertisement

Encryption/Decryption with bouncycastle-java and RSAES-OAEP

I am not an expert with encryption, but i am trying to create an CMSEnvelopedDataGenerator with bouncycastle 1.67, where the session key is encrypted with RSAES-OAEP (1.2.840.113549.1.1.7)

For now my code looks like this:

JavaScript

It runs through but when i check it via openssl asn1parse, i see

JavaScript

and then the hex dump. On my reference file it is like:

JavaScript

On line 143 at my file is the line

JavaScript

I am not sure where that comes from.

When i use my decryption code, which works for my reference file, i am getting the following exceptions

JavaScript

I hope its not much, that is missing.

Edit:

With my wrong generated file recipient.getKeyEncryptionAlgorithm().getParameters() results in

JavaScript

the correct file in

JavaScript

From where are these wrong NULL for SHA-256 values coming.

Advertisement

Answer

You only mention one ‘extra’ NULL in the BC-created message, but actually there are two, with the second one on the first line you excluded from the data you posted. The (different) length fields in your post, as well as the display of getParameters(), clearly show this.

Those NULLs are not wrong.

Those NULLs are the parameters for the hash algorithms in the parameters structure for OAEP, and are required by the standard. From RFC 3447 = PKCS1v2.1 which is the first version to include SHA-2 (in 2003, just after FIPS 186-2 in 2002) at A.2.1:

JavaScript

Observe that both hash specifications — the outer hash for the label and the inner hash within MGF1 parameters — are defined by infoset HashAlgorithm and all the defined values in that set, including SHA-256, have parameters explicitly NULL, not omitted as the generic X.509 ASN.1 permits (compare RFC5280 4.1.1.2 which uses the older pre-infoset notation).

Note the same is true for PSS in A.2.3, and with a slightly larger set of hash algorithms for the DigestInfo within RSASSA-PKCS1-v1_5 in A.2.4. This, and equivalent provisions in v2.0 (excluding PSS which wasn’t in 2.0, and with slightly different notation), may be in reaction to PKCS1v1.5 at 10.1.2 only making signature DigestInfo parameters a ‘should’ (lowercase even after 2119 presumably because this was RSALabs text not IETF), which led to variation in implementations causing signatures which were in fact correct sometimes to not verify, which was considered to be a bad thing in need of fixing.

Thus your ‘reference’ file is technically in violation of the standard. However, since these hash algorithms don’t actually use parameters — that’s why they are encoded with NULL — BouncyCastle can easily be tolerant and accept the omitted case. I tested with an otherwise valid structure and it does work both ways. (It wouldn’t surprise me if it even works with some inappropriate value like an octet string inserted there, but I didn’t test that.)

Even if the parameters encoding were wrong, it wouldn’t cause the exception you have — it would either be an explicit decoding/parsing error something like ‘required field missing’ or an instantiation error something like ‘invalid parameters for algorithm x’. In the absence of bugs, ‘bad padding’ is caused by damaged, tampered or otherwise wrong data (which in a CMS environment is very unlikely) or mismatched keys.

Check that you are using matching keys.

Advertisement