using AESCrypt.java to work with strings

[peterweinstein]

Hi,

I am trying to adapt AESCrypt to work with strings instead of text files. My unit test is below. I'm getting "Message has been altered or password incorrect" when trying to return the encrypted string back to the original. Your suggestions are much appreciated!

I'm also wondering if there are suggestions for what "something else" might be as in:
"It only works in Java 6, but can be easily adapted to Java 5
by replacing the call to NetworkInterface.getHardwareAddress()
with something else."

try
{
AesEncryption crypt = new AesEncryption(true, "123456");
String text = "original text";
InputStream input = new ByteArrayInputStream(text.getBytes("UTF-8")); // getBytes("UTF-8"));
ByteArrayOutputStream output = new ByteArrayOutputStream();

crypt.encrypt(2, input, output);
String encrypted = output.toString();
System.out.println("original=" + text);
System.out.println("length from " + text.length() + " to " + encrypted.length());
System.out.println("encrypted=" + encrypted);

InputStream input2 = new ByteArrayInputStream(encrypted.getBytes("UTF-8")); // UTF-8 -16 -16LE
ByteArrayOutputStream output2 = new ByteArrayOutputStream();

crypt.decrypt(encrypted.length(), input2, output2);
String decrypted = output2.toString();
System.out.println(" decrypted=" + decrypted);
} catch (Exception e)
{
e.printStackTrace();
System.out.println(e.getMessage());
}

Thanks!
Peter

[paulej]

Peter,

I didn't write the Java version of the code (though I did write the original C++ code). Assuming the Java code is producing that error for the same reason (which it likely is), it suggests that the HMAC is not being computed properly.

What the HMAC is for is to verify that the message was not altered in some way. AES has absolutely no way to know whether there is corruption or not. It merely takes a block and encrypts it. It then takes the next block and encrypts that. If two input blocks are identical, the encrypted output blocks are identical! It does a great job, bit it works at the "micro level" with no knowledge of anything outside of the block it is encrypting.

When encrypting a large file, you want to ensure that no two input blocks encrypt in the same way. You also want to have a means of knowing if a file is corrupted or not. Otherwise, you'll decrypt a file and it might be the wrong data or damaged data that comes out.

To ensure that no two identical blocks encrypt in the same way, AES Crypt employs a Cipher Block Chaining(CBC). This is important, because to mention, because this plays also into the production of the HMAC. The HMAC is implemented as per [url=http://www.packetizer.com/rfc/rfc2104/]RFC 2104[url].

If you wish to encrypt strings rather than a file, you can get rid of virtually all of the file overhead. You don't need the 'AES' prefix, the extensions, etc. If all of the strings you encrypt will be relatively short, you could also just use a single key to encrypt the string. AES Crypt has a two-key approach. The first key is used to encrypt 64 bytes of "initialization vector" and "encryption key". You could just go with a one-key approach. That's the way the first version of AES Crypt was (see file format 0):
http://www.aescrypt.com/aes_file_format.html

That simpler format 0 is very suitable encrypting strings. The only problem with it is that when decrypting large file, you had to get all the way to the end of the file and check the HMAC to see that the user typed in the wrong password. Short strings are no big deal. Big files were painful. So, I changed the code so that it only uses the key generated with the user's password to encrypt those 64 bytes you see in the current file format. The rest of the file is then encrypted with that key inside. That makes AES Crypt much faster for larger files.

Anyway, I would strongly recommend using file format v0 for encrypting strings. A side benefit of doing that is that if you encrypt the string and store the encrypted string in a file, you could then use AES Crypt (at least the C and C++ versions) to decrypt it, since all of the code I wrote supports all file formats defined.

Sounds like cool stuff... would be happy to lend a hand.

Paul