At least 3DES is *some* encryption. The issue is that peoples' computers are usually infested with malware; it's better to assume (for a software distribution) that the disk is compromised, and always encrypt it before writing.
Perhaps there should be a cipher option for the req -newkey option? -Kyle H On September 9, 2014 8:58:08 AM PST, Michael Wojcik <michael.woj...@microfocus.com> wrote: >As far as I know, openssl req doesn't let you specify the encryption >cipher for the private key. > >You can generate the key file first, with openssl genpkey, which does >let you specify the encryption cipher; and then use -key to tell >openssl to use your existing key rather than creating a new one. > >You can also do what you describe below, but not encrypt the private >key the first time, by using the -nodes option with openssl req; that >saves decrypting it before encrypting it with your preferred cipher. > > >Michael Wojcik >Technology Specialist, Micro Focus > > >From: owner-openssl-us...@openssl.org >[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop >Sent: Tuesday, 09 September, 2014 01:19 >To: openssl-users@openssl.org >Subject: Re: Certificate pass phrase brute force... > >I used the asn1parse command [thanks Dave!] and while the key looks >"old style" it parses as follows: > >50:d=4 hl=2 l= 8 prim: OBJECT :des-ede3-cbc > >Which appears to equate to: des-ede3-cbc Three key triple DES EDE >in CBC mode > >The full asn parse is: >--- > 0:d=0 hl=4 l=2446 cons: SEQUENCE > 4:d=1 hl=2 l= 64 cons: SEQUENCE > 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 > 17:d=2 hl=2 l= 51 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]:ABCABCABCABCABCA >(REDACTED) > 44:d=5 hl=2 l= 2 prim: INTEGER :0800 > 48:d=3 hl=2 l= 20 cons: SEQUENCE > 50:d=4 hl=2 l= 8 prim: OBJECT :des-ede3-cbc >60:d=4 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:ABCABCABCABCABCA >(REDACTED) >--- >[I don't know if I needed to redact those fields at all, but I don't >think it matters.) > >So, if I've read that properly, the encryption method is 3DES. > >--- >While this isn't really relevant to OpenSSL, and more relevant to the >EasyRSA script from OpenVPN - I thought I'd share a solution that >appears to work and do what I want. > >It doesn't appear easy to modify the EasyRSA script to use aes-256 [or >any non 3DES cypher] in the script. From my look at the syntax of a >"openssl req -new -newkey ..." command, you don't get to specify the >cypher it will use in encrypting the private key. This appears to be a >result of generating both the key and the signing request in a single >step - in this case you don't appear to get to choose what crypto is >used to encrypt the private key. [I'd be glad to be shown a way you can >specify it - it doesn't appear possible from the command-line options >at least.] > >However, as I pointed out there is code in the EasyRSA tool to >re-encrypt the private key with a new password, or remove the password. >You can edit the script to use aes256 as follows: [or any of the other >cyphers here: >https://www.openssl.org/docs/apps/rsa.html#<https://www.openssl.org/docs/apps/rsa.html>] >In the easyrsa bash script: >Look for the line: [ local crypto="-des3" ] (It's line 861 in the >current EasyRSA version) >Change it to: [ local crypto="-aes256" ] > >Now when you issue the command easyrsa set-rsa-pass, and issue the >"old" encryption key, along with a new one [you can certainly use the >same key for the old and "new"] it will re-encrypt it with aes-256. > >Looking at the key file it does appear to indeed work and re-encrypts >it with AES-256. > >#cat somekey.key >-----BEGIN RSA PRIVATE KEY----- >Proc-Type: 4,ENCRYPTED >DEK-Info: AES-256-CBC ... > >--- >Thus, this is the best work-around for the tool I can find. >Unfortunately it requires a "redundant" step unless someone can show me >a way to put the encryption type for private keys in a config file or >specify it as part of a "openssl -req ..." command > >But at least it works the way I want it to, and makes the task of >setting up keys and certs a bit easier than raw openssl commands. > >Hope that helps someone else too. And thanks again for all the pointers >and tips! > >[Ya'll are probably going to chuckle and say "If you'd just dumped that >lousy 'playskool' EasyRSA tool and run openssl like a real man, you'd >have avoided all this hoopla in the first place!" And yeah, you're >probably right - but I trust a good script to do it right more often >than I trust myself - but perhaps that trust is misplaced in this >case.] > >Again, glad for any follow-up advice - it's been an interesting thread >- at least for me. > >-Greg > > >For the legacy formats (dashes-BEGIN PRIVATE RSA KEY or PRIVATE EC KEY) >just look on the DEK-Info: header line. > >For PKCS#8 format (dashes-BEGIN ENCRYPTED PRIVATE KEY) do > openssl asn1parse <key.pem >and the third line will be an OBJECT (really OID) in the form >pbeWith<hash>and<cipher>. > > >From: >owner-openssl-us...@openssl.org<mailto:owner-openssl-us...@openssl.org> >[mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop >Sent: Monday, September 08, 2014 20:58 ><snip> >--On that note: Is there a way to determine from an encrypted key-file >what encryption was used to encrypt it? [I have the password, so it >doesn't need to be a blind test.] > > > >-- >Gregory Sloop, Principal: Sloop Network & Computer Consulting >Voice: 503.251.0452 x82 >EMail: gr...@sloop.net<mailto:gr...@sloop.net> >http://www.sloop.net >--- > >Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to >report this email as spam. > > >This message has been scanned for malware by Websense. www.websense.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
