I'm interfacing to a legacy Java application (the app cannot be changed) which is encrypting data using AES. Here is how the original Java code is instantiating the AES cipher:
SecretKeySpec skeySpec = new SecretKeySpec(key, "AES"); cipher = Cipher.getInstance("AES"); cipher.init(Cipher.ENCRYPT_MODE, skeySpec );
I'm a C/C++ developer, not Java, but from what I can tell this legacy Java code is not specifying the mode, nor the initialization vector. Anyone happen to know what Java would be using by default since it isn't specified?
We need the new C/C++ app to decrypt the Java-encrypted data. But I'm at a loss as to what to use for OpenSSL's initialization vector and chaining mode since I don't know what java does.
Possible answer found:
"By default, Java Ciphers (at least in Sun's implementations) are constructed in what is called Electronic Codebook (ECB) mode." (Source: http://www.javamex.com/tutorials/cryptography/block_modes.shtml)So if ECB is used by default, I guess that means no initialization vector, and I can use the following method from OpenSSL:
void AES_ecb_encrypt(*in, *out, *key, enc);
Using AES_decrypt()
I can decrypt 1000+ byte messages that originated on the Java side. So it looks like Java does indeed default to ECB mode with no initialization vector. However, I still cannot encrypt and send a new message to the Java app. Investigation continues.
Got it all working. Thanks for the numerous hints. I can confirm Java uses ECB
by default. All padding bytes are set to the number of bytes added (which is known as PKCS5-padding)."Hello World"
-> encrypted by Java -> decrypted using OpenSSL will look like"Hello World\5\5\5\5\5"
.