Encrypted private key in PKCS#8 format not supported

[Fire1nRain]

Encrypted private key in PKCS#8 format are not supported???
Only PKCS#5 format supported???
Is there any plan in adding the support?

[conradoplg]

The whole point of the library is to support encrypted PKCS#8, but not all cipher algorithms are supported. Can you give an example of key that is not supported?

[Fire1nRain]

@conradoplg since the library is called pkcs8, I assume it would support encrypted private key in PKCS#8 format.
I can't give an entire key since it is confidential, but it is in the form of

 -----BEGIN ENCRYPTED PRIVATE KEY-----
(base64 data)
 -----END ENCRYPTED PRIVATE KEY-----

Since it doesn't contain dek-info, the library will panic with a message "only PKCS #5 v2.0 supported"
I first thought the key was broken, but I later confirmed that the key is indeed encrypted and can be decrypted with openssl.

[conradoplg]

It does support PKCS#8... but just a subset of all possible ciphers and key derivation functions. PKCS#8 is just a container format.

PKCS#5 specifies the mechanism to encrypt data with a password, and it's used by PKCS#8.

Can you give the output of openssl asn1parse -in <keyfile>, omitting the confidential key material?

[Fire1nRain]

@conradoplg
here's part of the output

    0:d=0  hl=4 l=1308 cons: SEQUENCE
    4:d=1  hl=2 l=  78 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
   17:d=2  hl=2 l=  65 cons: SEQUENCE
   19:d=3  hl=2 l=  41 cons: SEQUENCE
   21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
   32:d=4  hl=2 l=  28 cons: SEQUENCE
   34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:75A0
   44:d=5  hl=2 l=   2 prim: INTEGER           :
   48:d=5  hl=2 l=  12 cons: SEQUENCE
   50:d=6  hl=2 l=   8 prim: OBJECT            :hmacWithSHA256
   60:d=6  hl=2 l=   0 prim: NULL
   62:d=3  hl=2 l=  20 cons: SEQUENCE
   64:d=4  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
   74:d=4  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:7B23
   84:d=1  hl=4 l=1224 prim: OCTET STRING      [HEX DUMP]:85E0
CB222B75ACDB2183B75A4D7F89B13F52221F30B16B02B500BD0CE89D6C004B
1378797F085751CB581AFA2F7D4244FC9FEEE88750BC9960147E509066A2B3

[conradoplg]

Weird. The "only PKCS #5 v2.0 supported" error happens when the library can't parse the ASN.1 structure, but it looks OK to me... The only weird thing is that the "INTEGER" doesn't show the integer value, did you delete it?

Is there anything after the last OCTET STRING you posted?

Can you provide a sample key that you can post, that raises the same error?

If you can't, can you provide out.der generated by openssl asn1parse -in rsakey.pem -strparse 4 -out out.der? (It should extract the PKCS#8 header, but not the encrypted key itself)

[Fire1nRain]

@conradoplg yes, I deleted the INTEGER, And the OCTET STRING has something in the end, I only copied a block of the whole output.
And sorry, but all the keys I generated seems to work fine with the library, this key is the only one that has some issue. And unfortunately this is the key I have to use.
The header this:

    0:d=0  hl=2 l=  78 cons: SEQUENCE
    2:d=1  hl=2 l=   9 prim: OBJECT            :PBES2
   13:d=1  hl=2 l=  65 cons: SEQUENCE
   15:d=2  hl=2 l=  41 cons: SEQUENCE
   17:d=3  hl=2 l=   9 prim: OBJECT            :PBKDF2
   28:d=3  hl=2 l=  28 cons: SEQUENCE
   30:d=4  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:75A044A37298FB4A
   40:d=4  hl=2 l=   2 prim: INTEGER           :0800
   44:d=4  hl=2 l=  12 cons: SEQUENCE
   46:d=5  hl=2 l=   8 prim: OBJECT            :hmacWithSHA256
   56:d=5  hl=2 l=   0 prim: NULL
   58:d=2  hl=2 l=  20 cons: SEQUENCE
   60:d=3  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
   70:d=3  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:7B237DBD69DAAE9F

[conradoplg]

@Fire1nRain sorry, I meant the out.der file that is also generated by that command, and has the raw headers. Can you please attach it?

[Fire1nRain]

@conradoplg Github doesn't support *.der, so I renamed it with a .txt
out.der.txt

[conradoplg]

The header is fine...

OK, I just realized what could be happening. What exactly are you passing to ParsePKCS8PrivateKey? If your key is PEM format (begins with -----BEGIN ENCRYPTED PRIVATE KEY-----), then you need to convert to DER format with pem.Decode, and pass the result to ParsePKCS8PrivateKey.

[dexxtreme]

From my initial testing for an internal tool I'm working on, the asn1 module is unhappy about encrypted ECDSA keys that were not created using PKCS#5 v2.0. For example, the following command always created a private key that could be decoded:

openssl ecparam -name prime256v1 -genkey | openssl pkcs8 -topk8 -v2 des3 -passout pass:password

However, the following command usually generated a key that causes an error in asn1:

openssl ecparam -name prime256v1 -genkey | openssl pkcs8 -topk8 -passout pass:password

In my case, the following error was generated:

asn1.StructuralError -- asn1: structure error: tags don't match (16 vs {class:0 tag:4 length:8 isCompound:false}) {optional:false explicit:false application:false private:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} pbkdf2Algorithms @2

I tested this by generating test keys using LibreSSL 2.6.5 and OpenSSL 1.0.2s on OSX (Homebrew). However, when running the above command using OpenSSL 1.1.1c it generates keys that work just fine because PKCS#5 v2.0 is the default on OpenSSL 1.1.x.

Right now I don't have time to figure out a workaround other than routing incompatible private keys through the openssl pkcs8 command...

[conradoplg]

@dexxtreme yes, the library doesn't support PKCS#5 v1.5... In order to support it, it would need to support a bunch of insecure ciphers or just some of them.