Decrypting data that was AES encrypted with Objective-C with Java

Question

I try to decrypt data that was originally encrypted with Objective-C in Java.

There are other questions mentioning this but they are really cluttered and many of them a

Answer 1

This is probably not contributing to your problem, but it's wrong anyway:

   char * keyPtr[kCCKeySizeAES128+1]; // room for terminator (unused)

That defines an array of kCCKeySizeAES128 + 1 pointers, not kCCKeySizeAES128 + 1 bytes. As it happens, it is OK because the buffer you get is four or eight times larger than you need depending on whether you are compiling for 32 or 64 bit.

Answer 2

1. I would not assume that CCCrypt supported using the same array for input and output. Try using two different arrays.
2. You have to resize the output array yourself (numBytesEncrypted should be equal to 16 after the call).
3. As far as I can see, a null IV signals using ECB-encryption instead of CBC. As long as your input is smaller than 15 bytes, it should not make any difference, but it is still something you should fix.

EDIT: Another issue:

4. You are using a 24-byte key. AES-128 needs a 128-bit = 16-byte key, AES-192 needs a 192-bit = 24-byte key and AES-256 needs a 256-bit = 32-byte key. You are explicitly indicating AES-128 to CCCrypt, which means it ignores the last 8 bytes of the key. You are just indicating AES to Java, which means it looks at the key-size to decide which AES variant to use. Since you are providing a 24-byte key, it uses AES-192. Fix it so both ends uses the same algorithm and you should be good.

Answer 3

You potentially have a bunch of issues.

When doing any encryption/decryption you need to ensure:

• string encoding is identical (you're using UTF8 in both, thats good)
• padding scheme is identical (you have pkcs5 on one and pkcs7 on the other)
• initialisation vector is identical (you have null on one and empty bytes on the other)

..and of course the encryption scheme is identical. Confusingly your encryption seems to be using AES128, although the comments discuss using AES256. Not sure what the Java version is using