Hi, I'm working on a Java utility to parse encrypted RSA and DSA keys.
http://juliusdavies.ca/commons-ssl/pkcs8.html To test this utility, I recently created a 2048 bit RSA private key, as well as a 2048 bit DSA key. I encrypted both of these using almost every single variation I could find in OpenSSL. In total I created 212 files, 106 each for DSA and RSA. The password to decrypt each of these (when encrypted) was "changeit": http://juliusdavies.ca/commons-ssl/samples/rsa_result.html http://juliusdavies.ca/commons-ssl/samples/dsa_result.html A few questions resulted. I might have more later, but for now I just have these 2. Question #1. ======================================== OpenSSL will output "SSLeay Traditional" encrypted keys using rc4, like so: openssl rsa -in openssl_rsa_unencrypted.pem -rc4 But it cannot decrypt the file that it produced! Is this a known bug? I also couldn't get my Java utility to decrypt it. I think the problem is that the encryption is salted, but that the salt is thrown away by accident. Notice this header in the PEM file: DEK-Info: RC4, Normally the salt is in there, right after the comma, for example: DEK-Info: BF-CBC,E59962EBB3DD3C74 Question #2. ======================================== The output of this seemed weird: openssl pkcs8 -in openssl_rsa_unencrypted.pem -topk8 -v2 des-ede http://juliusdavies.ca/commons-ssl/samples/rsa/pkcs8v2_rsa_des2_ecb_SEEMS_WRONG.pem It was the only time I managed to cause openssl to use "des2" when working with "-v2". I found it odd that it chose "ECB" instead of the usual "CBC"! I especially found it odd that the IV stored in the ASN.1 structure was set to all zeroes, although that turned out to be handy, as I'm a little suspicious that "1.3.14.3.2.17 - desEDE" could mean des3. (If I do "-v2 des3" it uses "1.2.840.113549.3.7 - DES-EDE3-CBC" instead.) It produced the following ASN.1 structure: DERObjectIdentifier: [1.2.840.113549.1.5.13] DERObjectIdentifier: [1.2.840.113549.1.5.12] DEROctetString: [9d40886adede6867 (length=8)] DERInteger: [2048] DERObjectIdentifier: [1.3.14.3.2.17] DEROctetString: [0000000000000000 (length=8)] DEROctetString: [probably binary (length=1224)] Every other "-v2" PKCS #8 encrypted key I created contained it's own IV. But in this odd case I had to use the key-derivation function to create the IV. The all-zeroes IV seemed to be just there to alert me that this was a special case. I suspect that openssl should really just spit out the "no object identifier" error in this case, like it does for some of the other ciphers that aren't available with "pkcs8 -topk8 -v2" (like "desx" or "des-ede3-cfb"). In other words, spit out this error! Error encrypting key 2579:error:0D0A706C:asn1 encoding routines:PKCS5_pbe2_set:cipher has no object identifier:p5_pbev2.c:102: (How often do people beg for errors on this mailing list!) ;-) But I've only been playing with this pkcs8 stuff for a month now. Maybe there's some poor mysterious legacy system out there that needs this! -- yours, Julius Davies 416-652-0183 http://juliusdavies.ca/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
