PKCS8 generated by openssl-1.1.+ cannot be decrpyted due to change of openssl encryption mechanism (-iter option to be precise)

aleksandar-kinanov commented 6 years ago

Steps to reproduce:

Generate keys the following way, using openssl-1.1.+ (I used 1.1.0):

ssh-keygen -t rsa -f ~/.ssh/testkey -C "testkey@exmaple.com"
ssh-keygen -f testkey.pub -e -m PKCS8 > testkey.pub.pem
openssl pkcs8 -topk8 -inform PEM -in testkey -out testkey.pem

The java code:

    try {
        JceOpenSSLPKCS8DecryptorProviderBuilder jce = new JceOpenSSLPKCS8DecryptorProviderBuilder();
        FileReader fileReader = new FileReader(privateKeyPath);
        PEMParser keyReader = new PEMParser(fileReader);
        JcaPEMKeyConverter converter = new JcaPEMKeyConverter();
        PKCS8EncryptedPrivateKeyInfo keyPair = (PKCS8EncryptedPrivateKeyInfo) keyReader.readObject();
        jce.setProvider("BC");
        InputDecryptorProvider decProv = jce.build(keyPassword.toCharArray());
        PrivateKeyInfo info = keyPair.decryptPrivateKeyInfo(decProv);
        keyReader.close();
        return (RSAPrivateKey) converter.getPrivateKey(info);

    }catch ( IOException | PKCSException | OperatorCreationException e) {
        e.printStackTrace();
        return null;
    }
}

Behavior: Throws exception : org.bouncycastle.pkcs.PKCSException: unable to read encrypted data: javax.crypto.BadPaddingException: pad block corrupted

Expected behavior: Read the key as it does with keys generated the same way as mentioned in 1. , but with openssl-1.0.2g (for example)

bcgit commented 6 years ago

I don't current have access to this version, if you can send me an example key as well will take a look at it.

dthompson085 commented 6 years ago

Works for me, but I can recreate that exception by using the wrong password -- are you sure you used the same password in the working and nonworking cases?

Note older Oracle/Sun JREs (below 8u151) require the 'unlimited policy', because 1.1.0 changed the default PBE from PBES1-MD5&DES (single DES!) to PBES2-hmacSHA256&AES256 and AES256 exceeds the old policy limit of 128, but that problem causes a very different exception, "Illegal key size".

aleksandar-kinanov commented 6 years ago

I will post the .pem private key which has password "testtest" and you can try to reproduce the issue.

NOTE: the key was generated under Ubuntu and I am trying to use it in Windows-based environment. I am not entirely sure if the issue might be related to the carriage returns or something of the likes.

dthompson085 commented 6 years ago

That file was not created by OpenSSL 1.1.0 pkcs -topk8 using defaults. Specifically, it is encrypted with pbes1-MD5&DES which was the default through 1.0.2, but in 1.1.0 this scheme is obtained only if you specify -v1 PBE-MD5-DES. You can see this for yourself with openssl asn1parse <file.

Although LF-vs-CRLF can be an issue in general between Unix and Windows, many things in Java particularly including BouncyCastle PEMParser/PEMReader use java.io.BufferedReader which handles both CRLF and LF and even old-Mac CR. And even if this were a problem, it absolutely wouldn't cause a decryption padding error, because decryption only occurs after the PEM data has been completely read and parsed successfully.

andreaceccanti commented 5 years ago

Is there a plan to provide a fix for this issue?

sebastiengoulet commented 2 years ago

@andreaceccanti do you know if there is any news regarding this bug, was it solved ?

bcgit / bc-java

PKCS8 generated by openssl-1.1.+ cannot be decrpyted due to change of openssl encryption mechanism (-iter option to be precise) #400