Java AES encryption with C/C++ AES decryption question

Question

I am doing a simple AES encryption in Java:

Cipher cipher = Cipher.getInstance("AES");
cipher.init(Cipher.ENCRYPT_MODE, getAES128SecretKey());
byte[] encrypted = cipher.doFinal(input);

The output is converted to hex and stored in a database.

A later process (one written in C/C++) comes along and reads the hex, converts it to bytes and decrypts it.

The issue is apparently the C implementation correctly decrypts the text, but also keeps extra bytes at the end that are unnecessary.

For example (not real values):

Java: encrypt("eric") -> 1234567890FFFFFF1234567890FFFFFF  (hex)
Java: decrypt("1234567890FFFFFF1234567890FFFFFF") -> "eric"
   C: decrypt("1234567890FFFFFF1234567890FFFFFF") -> "eric XXXX XXXX XXXX"

I do not own the C decryption algorithm and the party using it has suggested I append a null terminator character '\0' to the java bytes before encryption. My question is, would that work and should I even entertain that idea?

Reading the first answer to the question (while "unaccepted", sounds correct to me) Padding error when using aes encryption in java and decryption in c seems to be the correct way to go about this.

However, what if the string is encrypted in C and decrypted in C - will the C encrypted string now have issues whent decrypted in C and removing the padding as if it were a java encrypted string? Or would this be a non-issue?

Answer 1

Since AES is block cipher, you should pad data being encrypt to 16 bytes. Since C code doesn't deal with padding, probably it would report an error while encrypting, or add 'default' padding. Better, add padding by yourself.

Answer 2

The encryption / decryption process is largely irrelevant. After all, what comes in should be the same as what comes out. The question is what do the bytes representing the String object look like when written to a file.

A quick test confirms that when java writes a string to a stream neither the string nor the stream are null terminated. Consider the following code:

import java.io.FileWriter;
import java.io.IOException;

public SimpleStringIoTest
{
  public static void main (String[] args) throws IOException
  {
    String message = "Raw Java String";
    FileWriter fileWriter = new FileWriter("javaoutput.bin");
    fileWriter.write(message);
    fileWriter.close();
  }
}

Doing a hexdump of the file that it produces the following.

00000000  52 61 77 20 41 61 76 61 20 53 74 72 69 6e 67     Raw Java String

Therefore, when you encrypt that you end up with an 15 bytes of encrypted string and blocksize - 15 bytes of encrypted padding. When you decrypt this you get not only the string but also the plain-text padding, and unless you know the length of the plain-text or have an embeded plain-text terminator there is no way to know where the plain-text ends.

Using NUL ('\0') as the terminator makes sense, because this is also the terminator that C uses to mark the end of string. The ony possible problem is if NUL can somehow occur in your string already. Given that this would probably cause other issues with C/C++ programs I kind of doubt that, but you could always escape it away if it was a problem.

Oh, and I checked changing messages as follows:

String message = "Raw Java String\0";

Gives a hex dump of

00000000  52 61 77 20 41 61 76 61 20 53 74 72 69 6e 67 00  Raw Java String

Answer 3

The String issue and NULL padding is a distraction and potentially irrelevant. Java uses standard padding schemes (PKCS#5) to unambiguously allow the decryptor to know how many bytes of the final block need to be discarded. The C side of this also uses some scheme. You need to know what that scheme is. I would avoid attempting something like padding with '\0' until you know the padding algorithm that is expected by the C decryptor.

You should also explicitly request the padding and mode in the Cipher.getInstance() method rather than relying on defaults. For example, your usage is equivalent to Cipher.getInstance("AES/CBC/PKCS5PADDING") if you are using the Sun JCE provider, an excellent choice.