@Kyle: I'm the admin for the OpenVPN system setup and config, and generate all the server/client certs, CA etc., and if my machine is infested with malware, then well, the CA's compromised, along with everything else. IOW, game over.
It's not that I disagree with you particularly, but I doubt that the short time a private key is "exposed" before it gets re-encrypted, will matter much, especially in the very controlled situation I'm contemplating. [Which is actually inside a sterile VM.] --- @Michael: Yeah, I can use the EasyRSA tool to initially create the Key+CSR without a password [encryption-less] and then add the aes-256 re-key in the second process. [Like so: # easyrsa build-client-full somefilename nopass ] As I was writing up the post last night, I thought about describing that process, but thought it would confuse things further since I hadn't opened the thread that way... But yet, that will make it easier as I only have to input the password once into the terminal, instead of on both passes. And you're right in regards to modifying the EasyRSA script; it's more work than I'm able to do at the moment, and while I'm not terrible at bash, I'd be hesitant in making fairly major mods to [security critical] code in fear of introducing ill effects that won't get caught in a cursory peer-review. The current code can be made to work without too much hassle and has been around for a while and has been real-world tested. Unless the current maintainer is willing to do it, it's probably better to leave it the way it is now with the minor change I suggest. Again thanks all for the excellent help, ideas and suggestions. It's been a pleasure. [And that's an uncommon compliment - far more than can be said of many listservs.] -Greg Sure, if that's a better fit to your threat model. (I certainly wouldn't recommend changing "openssl req" to make -nodes the default.) I was just suggesting possibilities for Gregory. Personally, I'd probably go with generating an encrypted private key with "openssl genpkey" first, but that might be more changes to the EasyRSA script than he's inclined to make. He has a working solution now which seems fine for his purposes. A cipher option for "openssl req -newkey" wouldn't be a bad idea, but it's not a high priority, so I wouldn't expect it to happen anytime soon unless someone wants to submit a patch. Michael Wojcik Technology Specialist, Micro Focus From: Kyle Hamilton [mailto:aerow...@gmail.com] Sent: Tuesday, 09 September, 2014 13:43 To: openssl-users@openssl.org; Michael Wojcik Subject: RE: Certificate pass phrase brute force... 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#] 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] 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.] -- Click here 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.
