> From: owner-openssl-us...@openssl.org On Behalf Of Philip R. Landreth > Sent: Friday, 13 January, 2012 09:55
> The files were given to me in .txt format and the original file is a > .txt. as for the "keyfile" being in .txt I don't know. I used -p to > print the key and iv and used those instead of using -kfile. > iv did not > print as 8 zeros either it prints a 16 digit alpha numberic. The > encrypted file .txt is not readable(not alpha numeric) also when I add > -a it will output a blank .txt file. > You seem to have confused unrelated things, perhaps because I answered several questions. Let me try in pieces. One preliminary: The Java code you posted used the "contents" of keyfile_3des as the cipher key. First you need to know if readFileContents does anything other more complicated than its name says. One simple thing is to check the file size: if 24 bytes it is almost certainly a true "3key 3DES" key; if 16 bytes it is most likely a "2key 3DES" key (which you turn into a true 3DES key by duplicating K1); if anything else you'll have to find out what the file contains, and what part(s) of it are the actual key to use. The main point: OpenSSL 'enc' normally does password based encryption (PBE). PBE does *not* use the supplied password, even though it is sometimes called a key, as the key. It *derives* the actual key and IV *from* the password, plus the salt if used. If you do enc -k xyz or -kfile (contains-xyz) -nosalt etc. it uses a key and IV *derived from* xyz. If you add -p or -P it prints the *derived* key and IV in hex. These are *not* what the Java is using, and using them in OpenSSL will *not* give the same result as the Java. The Java uses the "contents" of the keyfile as the key *without* derivation, and it uses all zeros as the IV. If you want to do the same NON-PBE decryption with 'enc', you must use the "contents" of keyfile in hex with -K and eight 0s in hex with -iv. Hex uses 2 characters for each byte. A (true) 3DES key is 24 bytes and its IV is 8 bytes, but in hex they are 48 characters and 16 characters respectively, alphanumeric but restricted to 0-9 and A-F or a-f. Finally, the ciphertext (encrypted data): If the data file isn't (mostly) alphanumeric it isn't hex or base64 (and I said -a applies only if it's base64). But that doesn't confirm whether it is only the ciphertext or something that includes the ciphertext. As I said, msg.getBody().get() suggests there is more and only part of the file is the ciphertext, but you need to find out what that is, i.e. what .getBody() does; and also what .get() does but that sounds like it's probably simple. Then supply *that* data as -in or stdin to 'enc'. FWIW the only indexed JDK methods named getBody() are in java.net.CacheRequest java.net.CacheResponse and javax.xml.soap.SOAPEnvelope , and none of them returns a type that implements .get() , so this must be EE or similar or a third-party library or custom code. Using .txt for files that are not actually text or at least text-like tends to cause confusion, although it makes no difference to programs like OpenSSL. Unless something requires you to use particular names which are inaccurate, I suggest using accurate ones. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
