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 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
---
--
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gr...@sloop.net
http://www.sloop.net
---
