> From: [email protected] On Behalf Of Philip R.
Landreth
> Sent: Thursday, 12 January, 2012 09:33
> I was sent 2 files and a partial java code that another company uses
to decrypt.
<snip and realigned>
> byte[] encryptedData = (byte[])msg.getBody().get();
> byte[] decryptionKey = readFileContents("/keyfile_3des");
> final SecretKey key = new SecretKeySpec(decryptionKey, "DESede");
> _log.debug("Creating Cipher ...");
> final IvParameterSpec iv = new IvParameterSpec(new byte[8]);
> final Cipher decipher =
Cipher.getInstance("DESede/CBC/PKCS5Padding");
> decipher.init(Cipher.DECRYPT_MODE, key, iv);
> _log.debug("Performing Decryption ...");
> final byte[] decryptedData = decipher.doFinal(encryptedData);
> I am trying to get the same result with decrypting in openssl
> $ openssl enc -d -kfile keyfile_3des.txt -in
encrypt.20120109.160000.txt
> -out test1.txt -des-ede-cbc -nosalt
> I thought that the default padding for openssl was pkcs5 but I get
> what seems to me to be a padding error
> bad decrypt
> 140735237683644:error:06065064:digital envelope routines:
> EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:467:
The 'enc' utility normally does *password based encryption* which
derives the actual cipher key by a complicated hashing process.
-kfile takes the *password* from a file, not the actual key.
The only option that takes an actual key is -K and it doesn't read
from a file, so you'll have to get the key bytes, convert to hex,
and pass them to -K. Which may be insecure on an OS where other
processes can see process args, if anyone else can run programs.
With -K you must give -iv explicitly, also in hex; that Java code is
using 8 bytes of zero for the IV (which substantially reduces the
security benefit the IV is intended to provide) so you must also.
Alternatively write your own code which just calls the DES_ routines
directly or the EVP_Decrypt* routines with cipher=EVP_des_ede3_cbc().
It's probably about 20-40 lines as a standalone program (depending on
what options you need/want) or less as a function you integrate into
an existing program that uses the result if there is such. PKCS5 is
indeed the default for EVP_ and 'enc'; for DES_ you have to code it
yourself, but it's only a few lines even at most careful.
This shows up as a padding error because the raw decrypt operation
with the wrong key produces effectively random garbage, and the first
thing that looks at that data is the remove-padding operation which
says "hey, this is garbage, I can't do squat with it". With -nopad
you should still get garbage, it just isn't detected as such.
I'm also concerned that your filename is ".txt". If it is
readable (e.g. all or nearly all alphanumeric) then it is
(with overwhelming probability) not the actual ciphertext,
rather an 'armoring' such as commonly used base64 or hex.
If it is (only) base64 the 'enc' utility can handle that with
-a and maybe -A; for hex or other you must decode it yourself
before passing in (which you can do on standard input); and
for your own program you need to do either or whatever.
If the data is actually binary and you just named it ".txt"
it *might* be just the ciphertext, or it might be some other
format that *includes* the ciphertext, such as PKCS7/CMS DER.
Or HTTP-kindof-MIME. Or XML. Or who knows.
msg.getBody().get() suggests to me that there is some logic
involved in getting the ciphertext out of the message,
but you'll have to find out what that consists of.
The cast also worries me; AFAICS the only other Java type
than can be cast to byte[] is Object, and an API for .get()
that does that would be pretty weird. (Array-of-object types
can be elementally-upcast, but not array-of-primitive which
are implemented differently and have no up, or vice versa.)
If you find out this cast is not redundant and useless,
I'd be curious.
You also have .txt on the keyfile and readFileContents(keyfile)
might be doing something other than just reading the bytes,
although here the name is not so suggestive to me. If it is,
you need to do whatever that reading process is in the argument
to enc -K, or in your own code.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
