“RSA/ECB/OAEPWITHSHA256ANDMGF1PADDING”和“RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING”之间的区别是什么

Question

As per my knowledge both are same but one is working on one PC while same code says:

javax.crypto.NoSuchPaddingException: OAEPWITHSHA-256ANDMGF1PADDING unavailable with RSA on another machine.

When I am removing dash - from the name ( OAEPWITHSHA256ANDMGF1PADDING ) it starts running on another machine but leads error to some other line bad padding exception. What could be the reason?

Sample code for Hint

I am using jdk1.7.0_71 32bit :

private byte[] decryptSecretKeyData(byte[] encryptedSecretKey, byte[] iv, PrivateKey privateKey) throws Exception 
{
    try {

        Provider provider= new sun.security.pkcs11.SunPKCS11(keyStoreFile1);
        Security.addProvider(provider);

        LOG.info("**************Inside decryptSecretKeyData***********************");
        Cipher rsaCipher = Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING", provider);
        
        // decrypting the session key with rsa no padding.
        rsaCipher.init(Cipher.DECRYPT_MODE, privateKey); 

        /* The reason is RSA OAEP SHA256 is not supported in HSM. */
        byte[] decKey = rsaCipher.doFinal(encryptedSecretKey);

        OAEPEncoding encode = new OAEPEncoding(new RSAEngine(), new SHA256Digest(), iv);
        LOG.info("******************RSAPublicKey rsaPublickey = (*****************************");
        
        java.security.interfaces.RSAPublicKey rsaPublickey = (java.security.interfaces.RSAPublicKey) publicKeyFile;
        RSAKeyParameters keyParams = new RSAKeyParameters(false, rsaPublickey.getModulus(), EXPONENT);
        encode.init(false, keyParams);

        LOG.info("******************encode.processBlock(decKey, 0, decKey.length);************************");
        byte decryptedSecKey[] = encode.processBlock(decKey, 0, decKey.length);

        return decryptedSecKey;
    } catch (InvalidCipherTextException e) {
        LOG.info("*******************Failed to decrypt AES secret key using RSA :**********************");
        throw new Exception("Failed to decrypt AES secret key using RSA :" + e.toString());
    }

}

Answer 1

RSA/ECB/OAEPWITHSHA256ANDMGF1PADDING and RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING are different alias but both refers to the same algorithms, so in this sense there is not difference at all.

The thing is that you're using a PKCS#11 (cryptographic token interface) to cipher your data. According to java PKCS#11 reference :

The Sun PKCS#11 provider, in contrast to most other providers, does not implement cryptographic algorithms itself. Instead, it acts as a bridge between the Java JCA and JCE APIs and the native PKCS#11 cryptographic API, translating the calls and conventions between the two. This means that Java applications calling standard JCA and JCE APIs can, without modification, take advantage of algorithms offered by the underlying PKCS#11 implementations, such as, for example,

Cryptographic Smartcards, Hardware cryptographic accelerators, and High performance software implementations. Note that Java SE only facilitates accessing native PKCS#11 implementations, it does not itself include a native PKCS#11 implementation . However, cryptographic devices such as Smartcards and hardware accelerators often come with software that includes a PKCS#11 implementation, which you need to install and configure according to manufacturer's instructions.

Summarized, if you're using a PKCS#11 , the use of the algorithms depends on vendors native implementation ( .dll on windows, .so on linux ...) and some times on specific program connector so: check if in the both PCs you're using the same drivers/program version for your PKCS#11 token and the both are correctly installed because probably there is an error in one of them which doesn't allows you to use RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING correctly.

Hope this helps,

Answer 2

Both algorithms are provided by the different security provider. The

RSA/ECB/OAEPWITHSHA256ANDMGF1PADDING

is provided by the Bouncy Castle provider while

RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING

is provided by the SUN JCE provider. In our case, we are able to successfully use Bouncy Castle provider algorithm but if I replace that with SUN JCE algorithm then it gives following error:

Exception in thread "main" javax.crypto.BadPaddingException: lHash mismatch
at sun.security.rsa.RSAPadding.unpadOAEP(RSAPadding.java:425)
at sun.security.rsa.RSAPadding.unpad(RSAPadding.java:274)
at com.sun.crypto.provider.RSACipher.doFinal(RSACipher.java:356)
at com.sun.crypto.provider.RSACipher.engineDoFinal(RSACipher.java:382)

Answer 3

The situation is more complex. The RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING is nominally provided by SunJCE. The RSA/NONE/OAEPWITHSHA256ANDMGF1PADDING is provided by BC.

However BC is able to take over and act as a provider of RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING if it is installed before the SunJCE provider (using Security.installProviderAt). Unfortunately, BC does not parametrize this algorithm the same way as SunJCE does it. BC implementation of that algorithm is thus different (,) than one provided by SunJCE. which will be source of padding errors.

SunJCE RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING is using SHA-1 for MGF1 function and SHA-256 for label hash (which is almost always an empty byte array and therefore a static value).

BC RSA/NONE/OAEPWITHSHA256ANDMGF1PADDING is using SHA-256 for MGF1 function and SHA-256 for label hash. BC will also use the same parameters if it is being asked to provide RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING.

Advice: always explicitly specify security provider to make sure that correct provider is used. Alternatively explicitly specify the OAEP parameters and don't rely on defaults (recommended).

I've reported the issue to BC, so maybe it will get fixed.