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

[aleksandar-kinanov]

Steps to reproduce:

1. 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

2. 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)

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]

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]

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

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIE6TAbBgkqhkiG9w0BBQMwDgQId5R2WgoOjCMCAggABIIEyL1N3QThMW1pjijV
IEfZuCQy4YN/tffysCH2B1dlq8pFmc2bYzNDIzLyJKBUJdBTdT1NtMvoBC4gamcV
Z7UglN5jbyhxV3xLo/379SDBuNP6rXHpvlIRjqgEMzkaj8DF80Ao4owNjQ5BYrGp
yJBdCYf7HciUuXL0L7RbK/ctnk3lszY7Bi01phjNYSkBM8XTnv8NmnK3DXj3VnWO
+fSugMy7M9srQhEPRI7LsEueZczn7fSC0uLfQld+PhrJqovUa5oOWRXgsZgIq0Xx
xR0x3bdlCjKoBKeaWYfVpx2ot4OqadmbwjF2VSpWrhGkqUmKQzF8CzxKmKh4t3ZS
n5wJHBCwFY2nnFcnSOkjNPSKv/kbSiScS8kRsuIyjK3Ugg45aw06+iPCnWhhnWkw
IAmBIIf62+3exCSB31KTTj+xr5Vjnh/rNQD29rmGK9Jfa8IPiTR+Dvtg0e5nueqV
wcV0Fok+FMv5tMnLze/021is1f3hBd5/v99NF4cGsl5xCruiFvOTzKMRSYw/HIMS
ma737uIoXpSsEWeTSDHN/SQdQWpuhw5HUy7rx8j+EZv+39ZDiCNxb9QAAhskbdkx
IPs1FUcQdqxuVKuH1Irg18EsDG2piPk4OjQ8loigQpDlESRfa9//N1GwypGhsnZe
RYYM0tCUlsbQskheFON5ZIj+8FSfcnD74FxW1PwL32lPAOFWCHkJP7R7tYuCb7yg
752HFFPO8rXWEvb5bLX5MbbcnXq6k8uN3cCTpMJHs+NWGo/TvagIeS303xKAGTUK
MixGdDxmNZhLaFvviL8UPkAZsICSAkZ61eZeFXwbl9fqzQl3CyXflKILhcT8ntF/
yGIKIbcfJdZFeFtAycOltMS6WLI8DQ4O+TWg4vQpKdFkzg4NOh5p8K+ZHR434EOI
/qyBe/mQ3/Cq2c2fihdF5G/3htLIL09UBuiwBkW+hQD/jeNCIAWHK0ZT6M9F9KVW
oyifyl6YjKXN1LJznWIjrjcTxztmlikcE0sH86pU/VGpA14h4cntg22ZVYOYMwDv
HcFsW7Cs3Bm6C5yAnla+6crJSy58nIR8a7+fyxWAl0+G+rbYG1bCGSEZ0yet5Ml9
HWgjDud6xWNgDy1cjZKDFeIWLaTfMI+Y+q+RpOvav33rOLbgrsW3CsEmWcYKpfQC
JZgJGANOLHQ5ut6vqvC0BJ8DIjK0X2Y6gevtj0MbdmBxM5ER6Hxk1coLzS5DUe6A
I1Clkx8u7T/cI+ow4rno43XkWWYwxuW/TYoMZLmeFgwr1+8CaGOTR/iJRgswpjmv
sFygPrt9ujhHSs3oJ2ocm1bi8YXEA6jzkMrrxkSXnCakaRqiB7bEnC3J3NIn1ewp
E3HWUCE6jEl4T1XvgaYarkpnAv1XqcjbFPvxibSuDx4IkJW2+gkT5LLpcRvBYh6r
ENlpFMAwxuNCP9Nby2dc+oGwZ/31WjKLNO4nvCMFMiqHDz2geQ3esdFxyUjzKPx0
q52qw3HKmqA1nRE2+j+cWi9tdnXNdvYMBjrAqj+JKyiEe/co7OM5l52YwRHSk98K
ZZ6G5Gcl095XQb7amYXj8PGgim1NfqTmkV7cybSnj6oY79R9odNIbC6AVBCmv3Fb
HdNPxnebF94kNKiFwg==
-----END ENCRYPTED PRIVATE KEY-----

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]

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]

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

[sebastiengoulet]

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

[dghgit]

So we did find an issue related to the use of -topk8, This is now fixed and on https://www.bouncycastle.org/betas