(Sorry not inline, my Outlook can’t do that for HTML.)
That’s actually a subvariant I forgot to describe: PKCS#8 *version 2*.
It has “BEGIN ENCRYPTED PRIVATE KEY” (not specifying RSA etc.) like version 1,
but instead of a single PBE algorithm-id PBE-with-$kdf-and-$cipher it has a
structure
PBES2 with {$kdf-alg using $params} and {$cipher-alg using $params}.
So yes you read right, the cipher part is TDEA aka [3]DES[3]-EDE[3] in CBC mode.
Yes, req –newkey can only encrypt with TDEA. You can do that and then
re-encrpyt as you did; or you generate the key separately with genpkey
encrypting with any algo and then use req –new on that key.
Either way is two steps.
However, your conversion apparently produced a legacy-format file
“BEGIN RSA PRIVATE KEY” with DEK-Info. You/the script probably used
rsa -$cipher , which does this. This is MUCH LESS SECURE.
As I believe was mentioned, no one will bruteforce the data cipher,
neither TDEA nor AES-anything. Even 112 would take basically all the
computers on Earth for many many years, and 128 millions or more.
Even NSA can’t do that. What can be attacked is the password-based
derivation, especially if the password is something a human can remember.
And for backward compatibility the legacy-format files use a poor PBKDF –
based on PBKDF1 (slightly poor) WITH ITERATIONS=1 (AWFUL!!!).
If you want decent security at all, much less anything even approaching the
strength AES-256 appears to promise, use pkcs8 –topk8 –v2 $cipher
(which unobviously works for input that is already pkcs8) or pkey -$cipher .
Cheers.
From: <mailto:owner-openssl-us...@openssl.org> owner-openssl-us...@openssl.org
[ <mailto:owner-openssl-us...@openssl.org>
mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop
Sent: Tuesday, September 09, 2014 01:19
To: <mailto:openssl-users@openssl.org> 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: <mailto:owner-openssl-us...@openssl.org> 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: <mailto:gr...@sloop.net> gr...@sloop.net
<http://www.sloop.net> http://www.sloop.net
---
