proposal: crypto/x509: add support for PBES2 private keys

[shibe2]

What version of Go are you using (go version)?

1.14.3

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

I generated ECDSA private key with OpenSSL 1.1.1g using req -newkey. It asked for a password and encrypted the key. However, it didn't add headers like "Proc-Type" and "DEK-Info". If I decrypt the key using OpenSSL, it is usable for Go TLS, but Go itself cannot decrypt it.

https://play.golang.org/p/cU7jBbRIHt9

What did you expect to see?

IsEncryptedPEMBlock: true
key type: *ecdsa.PrivateKey

What did you see instead?

IsEncryptedPEMBlock: false
x509: no DEK-Info header in block

[shibe2]

From OpenSSL manual:

Normally a private key is written using standard format: this is PKCS#8 form with the appropriate encryption algorithm (if any). If the -traditional option is specified then the older "traditional" format is used instead.

So my key is encrypted using PBES2. It seems to be default for openssl pkey, openssl req and maybe some other sub-commands.

I wrote quick and dirty function to decrypt PBES2: https://play.golang.org/p/BK9rxDD87ur Feel free to use it if you decide to implement this feature.

EDIT: Added padding handling to my function.

[odeke-em]

Thank you for filing this issue @shibe2 and welcome to the Go project! I shall tag some experts @FiloSottile @katiehockman @retornam to also beware of this change.

@shibe2 if all goes great, perhaps this could be an addition to crypto/x509 or x/crypto/. Thank you.

[rsc]

What would it mean for crypto/x509 to support encrypted private keys? Where would it get the decryption keys?

[rsc]

Sorry, I missed x509.DecryptPEMBlock. I assume the proposal is to handle PBES2 in that function in addition to the current DEK-Info-based switch. Is there any header that is set in the PBES2-encrypted keys?

[shibe2]

PBES2 key blocks can be identified by PEM label (type) "ENCRYPTED PRIVATE KEY" and PKCS #5 object identifier in ASN.1 data. In an earlier comment I posted example code that handles both RFC 1423 and PBES2 encrypted keys.

[rolandshoemaker]

As far as I am aware PBES2 is vulnerable to the same classes of attacks as PBES1 due to lack of support for authenticated ciphers, which led to our deprecation of DecryptPEMBlock (see #41949 and #32777). If anything I think we probably want to add support for PKCS#8 encryption (see #8860).