RE: Certificate pass phrase brute force...
From: owner-openssl-us...@openssl.org On Behalf Of Gregory Sloop Sent: Monday, September 15, 2014 22:50 And, one more question: How can I tell what format/encryption my pkcs12 files are in? [I believe for Android platform use, I need p12 certs/keys - so I'm working on the export/conversion part too.] I export my cert+key like so: [openssl pkcs12 -export -aes256 -in somecert.crt -inkey somekey.key -out somep12.p12] An openssl pkcs12 -info -in somecert.p12 gives something like this: snip Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 My take on what that says [which may well be wrong.] The cert is protected with what appears to be quite a weak chpher, but we don't care, since it's public anyway. Right. However this looks like the key is encrypted with 3DES, but I exported it from the Cert+Key with -aes256 - so I'm puzzled why I'd have a 3DES encrypted p12. You thought you did but you didn't. The doc is a bit subtle, but the -$cipher option is listed under PARSING. It applies when *reading* a PKCS#12 and extracting the cert(s) and key(s?) to separate files or sections, for (most) other OpenSSL operations, and specifically to encrypting the extracted privatekey section. To specify the PBE algorithm for the key when exporting *to PKCS12*, use -keypbe, as listed on the man page under EXPORTING. And yes, it isn't very helpful that commandline doesn't warn when you specify a combination of options that doesn't make sense. This is true for most of the commandline functions historically, although a few that have been (re)written recently are better. snip earlier __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate pass phrase brute force...
[SNIP] However this looks like the key is encrypted with 3DES, but I exported it from the Cert+Key with -aes256 - so I'm puzzled why I'd have a 3DES encrypted p12. DT You thought you did but you didn't. DT The doc is a bit subtle, but the -$cipher option is listed under PARSING. DT It applies when *reading* a PKCS#12 and extracting the cert(s) and key(s?) DT to separate files or sections, for (most) other OpenSSL operations, and DT specifically to encrypting the extracted privatekey section. DT To specify the PBE algorithm for the key when exporting *to PKCS12*, DT use -keypbe, as listed on the man page under EXPORTING. DT And yes, it isn't very helpful that commandline doesn't warn when you DT specify a combination of options that doesn't make sense. This is true DT for most of the commandline functions historically, although a few that DT have been (re)written recently are better. Ah, that makes sense. A little quibble - not with the answer but with the way the command line tool works. I probably paid less attention to the man page than I should have since it *looked* like in the pkcs12 utility -aes256 was just like -v2 aes256 in the pkcs8 utility - but as you state, it's not. As stated, the switch in one is an input to the cypher, but an output for the other. Gack! [It's probably too late to do something different in the PKCS12 tool, but changing the way the switches work to make the two sub-tools operate in a more consistent way might be a good goal.] I'd guess that, even if I had read the manpage more carefully, I'd never have reached the conclusion that -aes256 wasn't going to do what I wanted. [To me, it was just obvious what it did, and I would have never questioned that assumption even though it was obvious it wasn't working like I thought and I was obviously wrong!] This was the last piece I needed - I can put this thing to bed now. Thanks again to all for all your great help! -Greg
Re: Certificate pass phrase brute force...
So, hopefully this will be the last post in the thread. [fat chance, eh!?]
I've gone back and re-encrypted the private keys [thanks Dave, again!] and this
is the result from an asn1parse
openssl asn1parse somepk.key
0:d=0 hl=4 l=2463 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]:...(REDACTED)
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-256-cbc
61:d=4 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:...(REDACTED)
79:d=1 hl=4 l=2384 prim: OCTET STRING [HEX DUMP] ...
Is that the new format? [It looks like it, but I'm such a babe in the woods,
I'd never know either way with any degree of certainty!]
---
One other related question: I assume more PBKDF key rounds increases the
computational difficulty of checking if some password works against the file.
[It's a trivial cost in general terms for a single or a few operations, but
becomes a greater and greater burden with an increasing number of tries. (Yes,
I know it doesn't *increase* in difficulty for more tries, it's the same
computational expense - but increasing a particular key try time/computational
cost by, say 0.3s is probably no big deal unless you need to do a few billion
a second.)
Do I have that conceptually right?
I read that the number of iterations is 2048.
It appears current versions of the openssl tool now have an option to change
-iter XXX where XXX is some number of iterations. [It's in the web/online
manpage, but not in my Ubuntu 14.04 openssl pkcs8 manpage...]
What version introduced the option to set the number of iterations? [I'm on
1.0.1f - which I thought should have it.]
I'm trying to do it like this: openssl pkcs8 -topk8 -iter 1 -v2 aes-256-cbc
-passin pass:somepass -passout pass:someotherpass -in source.key -out dest.key
[And yes, I also understand the risks of specifying the password on the command
line.]
Again, TIA!
-Greg
(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.
--
Gregory Sloop, Principal: Sloop Network Computer Consulting
Voice: 503.251.0452 x82
EMail: gr...@sloop.net
http://www.sloop.net
---
Re: Certificate pass phrase brute force...
And, one more question:
How can I tell what format/encryption my pkcs12 files are in?
[I believe for Android platform use, I need p12 certs/keys - so I'm working on
the export/conversion part too.]
I export my cert+key like so:
[openssl pkcs12 -export -aes256 -in somecert.crt -inkey somekey.key -out
somep12.p12]
An openssl pkcs12 -info -in somecert.p12 gives something like this:
---
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
...
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
localKeyID: 13 14 4F 31 89 4A E8 06 54 08 49 EA 5E 6D AE B6 39 F4 7F 01
Key Attributes: No Attributes
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-BEGIN ENCRYPTED PRIVATE KEY-
...
-END ENCRYPTED PRIVATE KEY-
---
My take on what that says [which may well be wrong.]
The cert is protected with what appears to be quite a weak chpher, but we don't
care, since it's public anyway.
However this looks like the key is encrypted with 3DES, but I exported it
from the Cert+Key with -aes256 - so I'm puzzled why I'd have a 3DES encrypted
p12.
Help! :)
-Greg
So, hopefully this will be the last post in the thread. [fat chance, eh!?]
I've gone back and re-encrypted the private keys [thanks Dave, again!] and this
is the result from an asn1parse
openssl asn1parse somepk.key
0:d=0 hl=4 l=2463 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]:...(REDACTED)
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-256-cbc
61:d=4 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:...(REDACTED)
79:d=1 hl=4 l=2384 prim: OCTET STRING [HEX DUMP] ...
Is that the new format? [It looks like it, but I'm such a babe in the woods,
I'd never know either way with any degree of certainty!]
---
One other related question: I assume more PBKDF key rounds increases the
computational difficulty of checking if some password works against the file.
[It's a trivial cost in general terms for a single or a few operations, but
becomes a greater and greater burden with an increasing number of tries. (Yes,
I know it doesn't *increase* in difficulty for more tries, it's the same
computational expense - but increasing a particular key try time/computational
cost by, say 0.3s is probably no big deal unless you need to do a few billion
a second.)
Do I have that conceptually right?
I read that the number of iterations is 2048.
It appears current versions of the openssl tool now have an option to change
-iter XXX where XXX is some number of iterations. [It's in the web/online
manpage, but not in my Ubuntu 14.04 openssl pkcs8 manpage...]
What version introduced the option to set the number of iterations? [I'm on
1.0.1f - which I thought should have it.]
I'm trying to do it like this: openssl pkcs8 -topk8 -iter 1 -v2 aes-256-cbc
-passin pass:somepass -passout pass:someotherpass -in source.key -out dest.key
[And yes, I also understand the risks of specifying the password on the command
line.]
Again, TIA!
-Greg
(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
RE: Certificate pass phrase brute force...
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 pbeWithhashandcipher. From: owner-openssl-us...@openssl.orgmailto: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
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#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
RE: Certificate pass phrase brute force...
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#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
Re: Certificate pass phrase brute force...
@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
Re: Certificate pass phrase brute force...
Having a sterile VM to do all of the cert generation is a good idea. But can you guarantee, in these days of logging and versioned filesystems, that the unencrypted key file data block will in fact be overwritten by the encryption? Or will it remain intact, with a new data block allocated for the new content? (Also, I'm trying to generalize good security principles to the design of a non-specific script. I now see that you have a particular scenario with a particular threat model in mind, and disclaim the creation of a solution for general utility.) -Kyle H On September 9, 2014 3:27:27 PM PST, Gregory Sloop gr...@sloop.net wrote: @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
RE: Certificate pass phrase brute force...
(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
RE: Certificate pass phrase brute force...
OK, that clarifies the situation and your question. It's impossible to provide a specific answer, because private keys can be encrypted with a variety of algorithms and key lengths. From https://www.openssl.org/docs/apps/rsa.html: -aes128|-aes192|-aes256|-camellia128|-camellia192|-camellia256|-des|-des3|-idea These options encrypt the private key with the specified cipher before outputting it. A pass phrase is prompted for. If none of these options is specified the key is written in plain text. This means that using the rsa utility to read in an encrypted key with no encryption option can be used to remove the pass phrase from a key, or by setting the encryption options it can be use to add or change the pass phrase. These options can only be used with PEM format output files. The computational complexity depends on the cipher. The difficulty of deriving the key depends on three things: the length of the passphrase (the external key), the length of the cipher's key (the internal key, which is generated from the external key), and whether there are any attacks better than brute force. We can disregard the last possibility. There are attacks on DES better than brute force, but they're not feasible. If there are better-than-brute-force attacks on any of the other ciphers, they haven't been published, and it's not worth worrying about them; you can't do anything about it. Regarding the first two, the relevant one will be determined by whether there's more entropy in the passphrase than in the internal cipher key. If your passphrase has, say, 180 bits of entropy, then you'd be discarding some entropy if you use AES-128 or Camellia-128. On the other hand, there's little benefit in that case to choosing AES-256 over AES-192. (There's potentially some benefit in making an attacker with limited knowledge do extra work.) But even if, let's say, you use a cipher with a 128-bit key, and your passphrase contains at least 128 bits of entropy, then an attacker is looking at 2^127 decryptions, on average, to brute-force the key. That's on the order of 10^38. If they can do a trillion (10^9) decryptions a second, they're still looking at around 10^22 years to recover the key. They'll probably get bored before then. Of course, your passphrases don't contain 128 bits of entropy. From your first message, you're talking about a random 10-character passphrase chosen from a 52-character alphabet. That's only about 57 bits, if I haven't made a mistake in my back-of-the-envelope calculations. So 2^56 decryptions on average to brute-force a key. With my theoretical trillion-decryptions-a-second attack, that'd take around two years. But 10^9 decryptions/second isn't a real-world value; I just made it up for the purposes of discussion. Osvik et al [2010]http://www.scs.stanford.edu/~deian/pubs/osvik:2010:fast.pdf reported a peak speed of 30.8 Gb/sec for AES software decryption; that's four years ago, but let's assume it's still fairly close to what any attacker is likely to mount against your system. You haven't said how long your private keys are; let's use the NIST recommendation of 2048 bits. So that gives us 1.6e7 key decryptions per second. So if the state of the art has improved by an order of magnitude since 2010, and if your attacker puts together a cluster of 100 such state-of-the-art machines, they could probably break one of your keys in a couple of months. That doesn't look like a plausible threat to me, unless you're protecting something really valuable. Disclaimer - I haven't double-checked any of those figures. Does that help? Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Friday, 05 September, 2014 16:32 To: Salz, Rich Subject: Re: Certificate pass phrase brute force... There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won't be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz I wasn't as clear in my initial post as I should have been. These are client _keys_ [as Michael Wojcik correctly points out, they're actually keys - sorry.] for OpenVPN to connect to the corporate network. You have to have a client certificate+key [generated by OpenSSL] and the pass-phrase given when the key was created. Pass-phrases are unique for each key. Pass phrases are created by the sys-admin [us], not the end user. I'll try to respond to several of the points in a single post. @dave: We can't limit the number
Re: Certificate pass phrase brute force...
of 2048 bits. So that gives us 1.6e7 key decryptions per second. So if the state of the art has improved by an order of magnitude since 2010, and if your attacker puts together a cluster of 100 such state-of-the-art machines, they could probably break one of your keys in a couple of months. That doesn't look like a plausible threat to me, unless you're protecting something really valuable. Disclaimer - I haven't double-checked any of those figures. Does that help? Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Friday, 05 September, 2014 16:32 To: Salz, Rich Subject: Re: Certificate pass phrase brute force... There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won?t be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz I wasn't as clear in my initial post as I should have been. These are client _keys_ [as Michael Wojcik correctly points out, they're actually keys - sorry.] for OpenVPN to connect to the corporate network. You have to have a client certificate+key [generated by OpenSSL] and the pass-phrase given when the key was created. Pass-phrases are unique for each key. Pass phrases are created by the sys-admin [us], not the end user. I'll try to respond to several of the points in a single post. @dave: We can't limit the number of attempts at the server side, since this will be an off-line attack. They've obtained our key, and are trying to brute-force the key pass-phrase. Essentially we'd assume an attacker is trying to break the encryption on the client.key [key] so they can use it. We aren't doing separate user verification. A valid certificate+key *is* the user validation. [It's the certificate+key, as well as the password. Without control of our CA, you can't generate another certificate+key, and the password is supposed to be kept separately from the key. It's not as much separation as other two-factor systems, but it's what we've got to work with.] --- @Rich / @Micheal Since IT generates the certs, IT gets to pick the pass-phrases. @Michael: Yeah, we ask the user not to store the key on the computer, and we try to generate passwords that are less work to remember and less likely to be stored on the PC. We ask that they write it down, rather than store it on the PC. But yeah - it's an issue and we're aware of the risk. @Rich / @Micheal As for attacking the machine: That's certainly a big issue - but again, if they don't have the pass-phrase, or know to capture it, they'll only get access to the OpenVPN network when the victim is connected [which is obviously bad]. But stealing the key and using an offline attack against it is the point I'm considering at the moment - even if it's, perhaps, a Maginot Line style pointless defense. [But the point about the vulnerability of the endpoint/workstation itself is clearly a valid one.] But the speed at which passwords can be tried against the key does matter - at least in trying to use the key themselves on another system. For example: Let say I send the key to a user via email. [I don't/wouldn't do this, but consider if I did.] Someone in the channel grabs it and starts working on it. If it's computationally expensive, then it will be much slower. If it's not, then one should plan for very long keys, or reducing the value of the pass-phrase via some other means. Part of the issue is: I don't know how computationally expensive this process is. [I really know almost nothing about it.] Does that help clarify? -Greg Click here to report this email as spam. This message has been scanned for malware by Websense. www.websense.com -- Gregory Sloop, Principal: Sloop Network Computer Consulting Voice: 503.251.0452 x82 EMail: gr...@sloop.net http://www.sloop.net ---
Re: Certificate pass phrase brute force...
I think it's safe to assume that 3DES is almost certainly a lousier choice
than AES or Camellia on multiple fronts.
Two key triple DES provides about 80-bits of security, and three key triple
DES provides 112-bits of security. Do you know which they are using?
AES-128 provides about 128-bits of security; and AES-256 provides about
256-bits of security.
If it was a new system, you probably would chose AES or Camellia. If they
are using three key triple DES with 112-bits of security, then there
shouldn't be any loud objections.
At those security levels, the adversary is not going to attack the block
cipher. They are going to attack the password or some other [weak] part in
the system.
Jeff
On Mon, Sep 8, 2014 at 4:00 PM, Gregory Sloop gr...@sloop.net wrote:
Continuing top posting. [Which doesn't bother me nearly as much as it
seems to bother others... ]
Yes! That was a fantastic answer.
...
[A while later]
So, I need to run this down, but it looks like the easy-rsa script uses
3DES to do encryption - which seems incredibly foolish when we have aes-256
available.
[Though I suppose 3DES is less computationally expensive for weak
processors - but still a bad trade-off, IMO Actually more reading seems
to indicate that perhaps 3DES is harder for general purpose CPU, but with a
smaller key-space. I'd guess a DES vs. AES specific processor would make
DES far more vulnerable {pulling that guess from, well, you know where...
:) }. ]
I think it's safe to assume that 3DES is almost certainly a lousier choice
than AES or Camellia on multiple fronts.
I've posed a question to the OpenVPN folks, about the EasyRSA script, and
it appears easy enough to change the encryption type in the script itself,
which I'll do if they don't.
Well, that was a fruitful question and personal research task. At least I
*know* more about the situation than I did before. It may, or may not,
change the entropy of my passwords, or make me do a lot different in the
future - but even if it doesn't - I'm a lot more knowledgeable about what's
going on and can make informed decisions about how to handle things from
here on.
So, thanks to all for your input.
BTW, I especially like:
If they can do a trillion (10^9) decryptions a second, they're still
looking at around 10^22 years to recover the key. *They'll probably get
bored before then.*
Sort of like the 3DES vs AES discussion here:
http://security.stackexchange.com/questions/26179/security-comparsion-of-3des-and-aes
...and quote ...
AES uses 128-bit blocks, for a limit of 2^128/2 blocks, i.e. 2^68 bytes,
also known as quite a lot of data
Thanks again!
...
Re: Certificate pass phrase brute force...
Well, as I said, given my reading of the code, the newest version of EasyRSA
[line 861] shows the following:
local crypto=-des3
It's in the set_pass function. [On further review of the code, this appears to
only be used by the set-rsa-pass or set-ec-pass functions, and I can't
determine what it uses to encrypt *new* CA/Server/Client keys instead of just
re-encrypting them.]
I'm certainly no bash guru, but it appears to only allow a 3DES encryption for
private keys
Again, all the thoughts about a tall fence, with a weak gate [i.e. attack the
end-device, instead of attacking the key by brute-forcing it, etc] all apply.
But even given those conditions, I think it's foolish choosing a weak
encryption for private keys when you don't absolutely need to do so. And
picking this in a public-use tool seems like a bad choice when many people
will use the tool [EasyRSA] believing that it's done using best practices.
All that said, I'm not entirely sure what it does use from reviewing the code.
[And I haven't had a reply to my query of the OpenVPN/EasyRSA folks, so I might
be entirely wrong.]
--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.]
If someone can give me that information, I can see what the EasyRSA code
actually produces. I can't find a way using OpenSSL - it will decrypt the key,
but doesn't tell me what it used to do so, or tell me about the encryption
method on the key. [But most of what the OpenSSL binaries do is far beyond my
very weak openssl-sauce, so that result isn't surprising.]
-Greg
I think it's safe to assume that 3DES is almost certainly a lousier choice than
AES or Camellia on multiple fronts.
Two key triple DES provides about 80-bits of security, and three key triple DES
provides 112-bits of security. Do you know which they are using? AES-128
provides about 128-bits of security; and AES-256 provides about 256-bits of
security.
If it was a new system, you probably would chose AES or Camellia. If they are
using three key triple DES with 112-bits of security, then there shouldn't be
any loud objections.
At those security levels, the adversary is not going to attack the block
cipher. They are going to attack the password or some other [weak] part in the
system.
Jeff
On Mon, Sep 8, 2014 at 4:00 PM, Gregory Sloop gr...@sloop.net wrote:
Continuing top posting. [Which doesn't bother me nearly as much as it seems to
bother others... ]
Yes! That was a fantastic answer.
...
[A while later]
So, I need to run this down, but it looks like the easy-rsa script uses 3DES to
do encryption - which seems incredibly foolish when we have aes-256 available.
[Though I suppose 3DES is less computationally expensive for weak processors -
but still a bad trade-off, IMO Actually more reading seems to indicate that
perhaps 3DES is harder for general purpose CPU, but with a smaller key-space.
I'd guess a DES vs. AES specific processor would make DES far more vulnerable
{pulling that guess from, well, you know where... :) }. ]
I think it's safe to assume that 3DES is almost certainly a lousier choice than
AES or Camellia on multiple fronts.
I've posed a question to the OpenVPN folks, about the EasyRSA script, and it
appears easy enough to change the encryption type in the script itself, which
I'll do if they don't.
Well, that was a fruitful question and personal research task. At least I
*know* more about the situation than I did before. It may, or may not, change
the entropy of my passwords, or make me do a lot different in the future - but
even if it doesn't - I'm a lot more knowledgeable about what's going on and can
make informed decisions about how to handle things from here on.
So, thanks to all for your input.
BTW, I especially like:
If they can do a trillion (10^9) decryptions a second, they're still looking at
around 10^22 years to recover the key. *They'll probably get bored before then.*
Sort of like the 3DES vs AES discussion here:
http://security.stackexchange.com/questions/26179/security-comparsion-of-3des-and-aes
...and quote ...
AES uses 128-bit blocks, for a limit of 2^128/2 blocks, i.e. 2^68 bytes, also
known as quite a lot of data
Thanks again!
...
RE: Certificate pass phrase brute force...
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 pbeWithhashandcipher. 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.]
RE: Certificate pass phrase brute force...
There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won't be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
Re: Certificate pass phrase brute force...
That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton
RE: Certificate pass phrase brute force...
[Apologies for top-posting; I'm using Outlook, and it's incapable of handling replies to HTML email properly. I'm sympathetic to its dislike of HTML email, but not to its inability to do things that BSD Mail managed to accomplish 30 years ago. Anyway...] First: Passphrases for certificates are of questionable utility. Passphrases for *private keys* are what most people want. A certificate is published information. Second: A 10-character passphrase drawn from an even random distribution of a 52-character alphabet is a near-mythical beast few will ever encounter. I don't see any advantage in incorporating it into your threat model, unless you're going to generate such passwords and force your users to use them. (And in that case they'll almost certainly record them somewhere, quite possibly in computer-readable form.) Password-cracking systems are successful for one or more of the following three reasons: - Users choose weak passwords. They choose natural-language words or predictable variations of them. They choose passwords that are too short. They choose passwords that are common and/or obvious (such as asdf). And so on. - Password-based security systems are often broken. There's a rich history and literature on the subject, so I won't bother going into details. This can certainly include passphrases applied to private keys (or certificates), when there are vulnerabilities in the mechanisms provided for managing and using those passphrases. There isn't a lot you can do if the user has installed malware that includes a keylogger, for example. - Technological advances have made password cracking significantly easier than it was when password-based authentication first started to be widely used. Hash-generation speed (as with the Elcomsoft system you mentioned) is NOT the most important of these. It's easy to obtain, store, and process large dictionaries of known passwords. It's feasible to get and use large clusters of systems for dictionary attacks. It's feasible to use rainbow tables. And so on. But really the first two points are the downfall of most password-based authentication. Throwing technology at the problem helps, but not nearly as much as poor user practice and poor system design and implementation. When a user's credentials are compromised, it will almost certainly be because they did something wrong, or an application developer did something wrong, or a system administrator did something wrong. I'm not in the business of issuing certificates and keys myself, so I don't have any policies to share, I'm afraid. Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Gregory Sloop Sent: Friday, 05 September, 2014 13:37 To: openssl-users@openssl.org Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg Click
Re: Certificate pass phrase brute force...
I most certainly did NOT hack into anything. I thank you so much for your response, but deplore your rudeness Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: dave paxton dpax...@me.com Date:09/05/2014 3:33 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Re: Certificate pass phrase brute force... That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton
Re: Certificate pass phrase brute force...
Perfect. No rudeness here. Just ideas. I do think that relying on a password as a base system for the private key will be the Achilles heal of any system. Even if you allow for CAPS you will soon have systems that will try to pass these in a few million times a second. As an administrator looking for the best route to take then always allow for all of the past mistakes made by others to be taken into account. Wide open systems allow for wide open attacks. On 9/5/2014 1:51 PM, flgirl799901 wrote: I most certainly did NOT hack into anything. I thank you so much for your response, but deplore your rudeness Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: dave paxton dpax...@me.com Date:09/05/2014 3:33 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Re: Certificate pass phrase brute force... That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton
Re: Certificate pass phrase brute force...
je comprends pas ce qu'il se passe Le 5 sept. 2014 22:04, dave paxton dpax...@me.com a écrit : Perfect. No rudeness here. Just ideas. I do think that relying on a password as a base system for the private key will be the Achilles heal of any system. Even if you allow for CAPS you will soon have systems that will try to pass these in a few million times a second. As an administrator looking for the best route to take then always allow for all of the past mistakes made by others to be taken into account. Wide open systems allow for wide open attacks. On 9/5/2014 1:51 PM, flgirl799901 wrote: I most certainly did NOT hack into anything. I thank you so much for your response, but deplore your rudeness Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: dave paxton dpax...@me.com dpax...@me.com Date:09/05/2014 3:33 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Re: Certificate pass phrase brute force... That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.net gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg -- Dave Paxtondpaxton@me.com208 570 9755 skype: dpaxton -- Dave Paxtondpaxton@me.com208 570 9755 skype: dpaxton
RE: Certificate pass phrase brute force...
Very few attackers are going to bother with an online attempt to crack a password, except when a (broken) system provides an oracle for validating password attempts. They'll get a copy of a password verifier (such as a salted hash or something encrypted using the password) and perform an offline attack. That's been the preferred mode since, oh, the late 1980s? Stoll describes an offline attack against the UNIX password file (this is before the shadow file was widely used) in The Cuckoo's Egg (1989). Generally speaking, if brute-force password cracking is a significant threat in your threat model, your remediation probably needs to include a lot more than throttling online attempts. In fact, throttling online attempts often creates worse vulnerabilities, including DoS vulnerabilities and outright breaks when deliberate throttling is combined with social engineering (forged password-rest requests and the like). Michael Wojcik Technology Specialist, Micro Focus From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of dave paxton Sent: Friday, 05 September, 2014 15:34 To: openssl-users@openssl.org Subject: Re: Certificate pass phrase brute force... That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.netmailto:gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Cc: Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg -- Dave Paxton dpax...@me.commailto:dpax...@me.com 208 570 9755 skype: dpaxton Click herehttps://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== to report this email as spam. This message has been scanned for malware by Websense. www.websense.com
Re: Certificate pass phrase brute force...
There is nothing special about cracking a certificate password versus any other password. There is a lot of literature out there; a web search will easily give you enough information to be depressed. I think your biggest faulty assumption is that your users will pick truly random 10char passwords. And the second-biggest is that the other attacks on their platform (windows?) won?t be more effective, anyway. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz I wasn't as clear in my initial post as I should have been. These are client _keys_ [as Michael Wojcik correctly points out, they're actually keys - sorry.] for OpenVPN to connect to the corporate network. You have to have a client certificate+key [generated by OpenSSL] and the pass-phrase given when the key was created. Pass-phrases are unique for each key. Pass phrases are created by the sys-admin [us], not the end user. I'll try to respond to several of the points in a single post. @dave: We can't limit the number of attempts at the server side, since this will be an off-line attack. They've obtained our key, and are trying to brute-force the key pass-phrase. Essentially we'd assume an attacker is trying to break the encryption on the client.key [key] so they can use it. We aren't doing separate user verification. A valid certificate+key *is* the user validation. [It's the certificate+key, as well as the password. Without control of our CA, you can't generate another certificate+key, and the password is supposed to be kept separately from the key. It's not as much separation as other two-factor systems, but it's what we've got to work with.] --- @Rich / @Micheal Since IT generates the certs, IT gets to pick the pass-phrases. @Michael: Yeah, we ask the user not to store the key on the computer, and we try to generate passwords that are less work to remember and less likely to be stored on the PC. We ask that they write it down, rather than store it on the PC. But yeah - it's an issue and we're aware of the risk. @Rich / @Micheal As for attacking the machine: That's certainly a big issue - but again, if they don't have the pass-phrase, or know to capture it, they'll only get access to the OpenVPN network when the victim is connected [which is obviously bad]. But stealing the key and using an offline attack against it is the point I'm considering at the moment - even if it's, perhaps, a Maginot Line style pointless defense. [But the point about the vulnerability of the endpoint/workstation itself is clearly a valid one.] But the speed at which passwords can be tried against the key does matter - at least in trying to use the key themselves on another system. For example: Let say I send the key to a user via email. [I don't/wouldn't do this, but consider if I did.] Someone in the channel grabs it and starts working on it. If it's computationally expensive, then it will be much slower. If it's not, then one should plan for very long keys, or reducing the value of the pass-phrase via some other means. Part of the issue is: I don't know how computationally expensive this process is. [I really know almost nothing about it.] Does that help clarify? -Greg
Re: Certificate pass phrase brute force...
If someone has the encrypted key data, they can feed that data anywhere they wish. In that case, they can feed it into processing systems that do not enforce rate-limiting. Thus, there is no way to do what Dave Paxton suggests in any case. -Kyle H On September 5, 2014 12:51:04 PM PST, flgirl799901 flgirl799...@gmail.com wrote: I most certainly did NOT hack into anything. I thank you so much for your response, but deplore your rudeness Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: dave paxton dpax...@me.com Date:09/05/2014 3:33 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Re: Certificate pass phrase brute force... That is easy. Just restrict the number of different passwords per day. Any account. Thus the old school brute force idea passes out the window. Most of what you are looking at it a signing issue. Basically one person does a transaction and the the other person verifies it. They do the DSA and thus they are the same person as they should be. That is the idea anyway. As far as accounts go that hold those keys then you have the few problems. Did the client get hacked or you? Who can hack the account like our recent icloud picture issue. All of this is lazy programming. It is really a matter of how certain you are of the client and how you want to make sure they are who they are. No biggie. Dave. On 9/5/2014 1:03 PM, flgirl799901 wrote: How do I unsubscribe from all of this? Sent via the Samsung GALAXY S® 5, an ATT 4G LTE smartphone Original message From: Gregory Sloop gr...@sloop.net Date:09/05/2014 1:36 PM (GMT-05:00) To: openssl-users@openssl.org Cc: Subject: Certificate pass phrase brute force... General question: I've done a number of searches and can't find a lot about the subject. [I've searched the list archives too...at least as best I could.] In several cases, the most obvious being OpenVPN, I use client certificates generated by openssl, with a pass-phrase [password]. This means that if I ever have someone misplace the certificate, it can't be used without the password. [And I have little control about what users do with such things - they download and install software they shouldn't; They have unknown users use their machines; They get their machines/phones/tablets stolen etc.] However, if someone loses control of the certificate, I need to consider the safety of the certificate. [And I have to assume I'll never know they lost control of it either.] Assume users are practicing reasonable security and it's unlikely an attacker will obtain the pass-phrase when they obtain the certificate. [A hard/bad thing to assume, I realize.] So, I've seen reports of Elcomsoft's tool to attempt ~6K passwords a second against a certificate file. Let's assume two orders of magnitude better performance for a fairly determined attacker, and we're at 600K passwords per second. Three gets us 6M a second. But even at 6M a sec, a non dictionary guessable pass-phrase of 10 characters will require ~380 years to break - which isn't too bad, IMO. [Assume a 52 character set. This obviously gets complicated since the pass-phase probably isn't completely random etc...but lets assume a theoretical 52 character random set.] But since I can't find any reputable source for this kind of data, I'm questioning the assumptions above. Can anyone give me some pointers at a reputable attempt at quantifying this? [The brute-force-ability and the speed at which it might be accomplished.] Does anyone have a policy about loss of certificates and regeneration/revocation along with the underlying reasoning they're willing to share? Or, perhaps I completely misunderstand what's going on, and I'd be glad to be corrected. [Gently is always nice.] TIA -Greg -- Dave Paxton dpax...@me.com 208 570 9755 skype: dpaxton -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
