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 10000 -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
---
