On 27/10/2015 03:42, Viktor Dukhovni wrote: > 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----- I forgot about the IV (the others could be automagically guessed by code trying each in turn or based on options). > 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. Automatically switching methods would be just as big a surprise (but at least not as insecure) as the current behavior,so as long as pkey produces the "old SSLeay" PEM-needing format by default, the best solution would be to fatally reject attempts to produce that format is DER. Of cause there should be no fatal error if other options indicate a request for an unencrypted key (e.g. -nodes) or a format that works without extra PEM fields (e.g. PKCS#8). However to the extent not already there, there really should be an option to select between "old SSLeay" and PKCS#8 with various PBE algorithms. Preferably based on similar options in other openssl subcommands (apps), such as the -v1 and -v2 options to the pkcs8 subcommand, the additions would be -v0 alg for the old format and -nodes for not encrypting on output. Ideally, this could go in shared code used by all the private key file writing subcommands (apps). This is needed because some programs require the old input format for encrypted keys, while others require PKCS#8 (and a few accept either with autodetect). Transition proposal: Initially, a patch for supported OpenSSL versions would simply add the fatal error when trying to output the old encrypted private key format as DER. Next the version after 1.0.2 could add consistent private key encryption options to all the affected apps, while keeping the historic defaults of each command. Documentation would encourage explicitly specifying the desired format even if it happens to be the current default. Then after a long transition period (to get all manner of administrator scripts, tutorials and distribution tools updated), the defaults could change to something more consistent, but this would be years into the future. Think time between "LTS" distribution releases (varies by vendor), plus the traditional 5 year upgrade cycle in professional enterprises. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
