On Tue, Oct 27, 2015 at 02:21:13AM +0100, Jakob Bohm wrote:
> More specifically, the issue is that the currently
> recommended command "openssl pkey", allegedly silently
> omits the encryption when told not to Base64 encode the
> encrypted key.
I agree this is a bug, and needs to be fixed. A fatal error seems
best for now.
Encrypting the DER object is more difficult, since the result needs
to be able carry algorithm and IV metadata, which in the PEM version
is *not* part of the base64 encoding.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,BCD9FB9A94F887A6CD391BBB244D01FC
... base64 bits...
-----END RSA PRIVATE KEY-----
For this to be generically possible with DER payloads, we'd need
a new ASN.1 type for this type of encapsulation, which starts to
look rather like a generalization of PKCS#8. Below is asn1parse
output for a v2 pkcs8 object that uses aes-128-cbc.
0:d=0 hl=4 l= 719 cons: SEQUENCE
4:d=1 hl=2 l= 73 cons: SEQUENCE
6:d=2 hl=2 l= 9 prim: OBJECT :PBES2
17:d=2 hl=2 l= 60 cons: SEQUENCE
19:d=3 hl=2 l= 27 cons: SEQUENCE
21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2
32:d=4 hl=2 l= 14 cons: SEQUENCE
34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:C81795B560A892AA
44:d=5 hl=2 l= 2 prim: INTEGER :0800
48:d=3 hl=2 l= 29 cons: SEQUENCE
50:d=4 hl=2 l= 9 prim: OBJECT :aes-128-cbc
...
That would not be a simple or compatible change, so "pkey" would
need to automatically switch to "pkcs8" when DER output is requested
in combination with encryption, and there'd need to be some logic
around automatically selecting v1.5 vs. v2.0 PBE algorithms.
Is there a suitable standard DER format for generically encrypted
objects that can generalize and replace PKCS#8?
--
Viktor.
