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