bc-java

bc-java copied to clipboard

SunJCE in RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING is using SHA-256 for label hash and SHA-1 for MGF1 (if parameters are not present). BC is using SHA-256 for label hash and for MFG1 both for its own RSA/NONE/OAEPWITHSHA256ANDMGF1PADDING and when "simulating" SunJCE's RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING.

This leads to padding errors which are difficult to resolve since both parties are referring to the same algorithm by its name but underneath it is really different padding.

Expectation: either support SunJCE algorithm name as SunJCE does it or don't support it at all since if BC is installed before SunJCE it will take over SunJCE algorithm name.

This can be fixed by changing conditions at https://github.com/bcgit/bc-java/blob/bc3b92f1f0e78b82e2584c5fb4b226a13e7f8b3b/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/rsa/CipherSpi.java#L225 to use proper MFG1 hash when matching against SunJCE names.

We're not simulating anything.

This is actually a known defect in the SUN provider - the MGF PRF should operate at the same level of security as the hash being used for the message digest. I'll admit the situation kind of sucks, but our OAEP implementation is actually the older one, and this issue over the PRF used in MGF1 was raised as a bug against the SUN provider years ago as no-one else did this either. Apart from that in a FIPS environment the SUN interpretation is most definitely wrong. I think we're all stuck.

You can use the OAEPParameterSpec parameters to trigger a compatible implementation. These should be provided with the encrypted data. The ASN.1 should show that SHA-256 is used for the label and that SHA-1 is the MGF PRF.

Ok. I understand that point of view and it is a valid one. Security is important and this is a focus for BC.

However, there is another point of view that could be also taken into account.

The SunJCE bug (or deficiency) became a feature. There are just so many places this padding "RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING" with default settings, that if it was fixed it would break hundreds of applications. JDK-7038158 (or other related) is not going to be fixed at all in foreseeable future. The only way SunJCE could fix this bug is if it deprecate the old padding and introduce new one that is differently named. Default setting for the existing padding will never change due to prevalence of its usage.

However, this deficiency of SunJCE and different behavior of BC made its way to android keystore (https://developer.android.com/guide/topics/security/cryptography#oaep-mgf1-digest) were it was acknowledged and became a feature as well. So fixing it in BC would create an backward incompatibility for Android platform.

At this point I think that we will have to live with this confusion until new naming for OAEP padding is invented. The only thing that can be done is to put warning (maybe in Javadoc) not to use "default" non-parametrized OAEP padding at all, cause you can never be sure what will be its parametrization (because it depends on platform and ordering of security providers).