CODEWITHSUNDEEP
javaencryptioncryptographyaes
vikingsteve
vikingsteve

Reputation: 40428

Java AES encryption: need files to decrypt properly in freely available decryptor tools

I am using Java AES encryption to encrypt data which will be sent to a recipient. Each recipient will have their own key, which both they and I know.

The idea is that they can decrypt the data using freely available AES decryption tools.

Here is the my code:

public class AESencrypt {

    private static final String ALGO = "AES/CBC/PKCS5Padding";
    private static final byte[] keyValue = new byte[]{'T', 'h', 'e', 'B', 'e', 's', 't', 'S', 'e', 'c', 'r', 'e', 't', 'K', 'e', 'y'};
    private static byte[] iv = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };

    public void String encryptToFile(String filename, String data) throws Exception {
        Key key = new SecretKeySpec(keyValue, "AES");
        Cipher c = Cipher.getInstance(ALGO);
        IvParameterSpec ivspec = new IvParameterSpec(iv);
        c.init(Cipher.ENCRYPT_MODE, key, ivspec);
        byte[] encVal = c.doFinal(data.getBytes());
        FileOutputStream fileOutputStream = new FileOutputStream(filename);
        fileOutputStream.write(encVal);
        fileOutputStream.close();
    }

    public static void main(String[] args) throws Exception {
        encryptToFile("foo.aes", "hellothere");
    }
}

}

To verify this, I used an Online AES Encryption / Decryption Tool to decrypt some sample data (which worked fine!).

Now, I would like to use a free AES decryption tool so that the recipients can decrypt the data on their PC without using an online tool - and here is where the frustration starts.

I started installing and testing out various different AES decryptor tools: I carefully enter the key, choose the CBC algorithm, select my file and hit "decrypt", and yet none of the tools can decode my sample file foo.aes - they all fail with errors and in one case gave an empty file of zero bytes.

I tried this with at least 4 different AES encryptor/decryptor tools, and none of them worked to decrypt my file, which leads me to believe there might be a problem with my code.

If anyone can look over my code that would be greatly appreciated.

Alternatively there may be an AES decryptor tool that will work with the code above.

Upvotes: 1

Views: 1278

Answers (4)

vikingsteve
vikingsteve

Reputation: 40428

Well in the end I think I found a nice solution.

There is some Java source code at AES Crypt and a corresponding lightweight utility program that you can share with users who need to decode the AES files you generate.

It seems like a good approach to me, unless anyone can say otherwise?

Upvotes: 0

ntoskrnl
ntoskrnl

Reputation: 5744

The problem you're facing is that while AES is a standard, it's just a cryptographic primitive, and you need a full protocol.

The protocol you've come up with works basically as follows:

  • Pre-share the secret key somehow. The key is defined as 16 characters in the ASCII character set; a key derivation function should not be applied to it (pre-defined details).
  • Encrypt the plaintext with AES, in CBC mode, with PKCS #5 padding (pre-defined details). Use a pre-defined IV.

As you see, there are several pre-defined details that both parties must be aware of for successful communication, and AES is only one of them. The tools you've tried apparently don't agree on all these details.

The solution is of course to use a standard protocol.

To choose an appropriate protocol, you must first determine why you need encryption, because encryption per se is not desirable goal. What are you trying to protect against?

In essence, encryption substitutes the confidentiality of a large amount of data with that of a small amount of data (the key). What happens if the user leaks the key by mistake? If you can securely send the key to a user, why can't you send the rest of the data through that channel too? (An article on the subject: http://blogs.msdn.com/b/ericlippert/archive/2011/09/27/keep-it-secret-keep-it-safe.aspx)

It is also important to realize that confidentiality is only one of many security properties. Your protocol fails to provide authenticity (guarantee that you created the message and that it has not been modified), because CBC is fairly malleable, and it may leak information about the plaintext, because you used a static IV.

As you can see, designing a secure protocol is far from easy. You must be aware of even the most minute details of your decisions. Even experts don't always get it right.

To avoid all the hassle, your best option is to use a well-established standard. Use TLS for transferring data over a network connection, and PGP for encrypting data on disk. Both protocols are configurable for almost any use case.

Upvotes: 2

Eugene Mayevski 'Callback
Eugene Mayevski 'Callback

Reputation: 46080

Symmetric encryption (even with the same encryption algorithm) can be used in a number of ways and the product is then wrapped in another myriad of methods. Chances that two developers that don't follow some particular specification will produce the same output are close to zero.

I bet that those applications you've mentioned don't handle each other's output, i.e. they are not mutually compatible as well. If they are, then this means that they follow some standard or other document and then you need to implement the same standard.

Upvotes: 0

anotherUser
anotherUser

Reputation: 561

You have 100 programmers => 100 different ideas. What im trying to tell here is that maybe your code and lets say [CriptAES] are giving same output, but they [programmers of CriptAES for example] added some additional check/encryption/something so you cant decrypt it with any other tool. Maybe they are forcing users[people who use their tool] to use only that application [CriptAES] for encryption and decryption. Its just idea, nothing more. Good luck.

Upvotes: 0

Related Questions