Question

The application I am working on lets the user encrypt files. The files could be of any format (spreadsheet, document, presentation, etc.).

For the specified input file, I create two output files – an encrypted data file and a key file. You need both these files to obtain your original data. The key file must work only on the corresponding data file. It should not work on any other file, either from the same user or from any other user.

AES algorithm requires two different parameters for encryption, a key and an initialization vector (IV).

I see three choices for creating the key file:

1. Embed hard-coded IV within the application and save the key in the key file.
2. Embed hard-coded key within the application and save the IV in the key file.
3. Save both the key and the IV in the key file.

Note that it is the same application that is used by different customers.

It appears all three choices would achieve the same end goal. However, I would like to get your feedback on what the right approach should be.

Answer 1

As you can see from the other answers, having a unique IV per encrypted file is crucial, but why is that?

First – let’s review why a unique IV per encrypted file is important. (Wikipedia on IV). The IV adds randomness to your start of your encryption process. When using a chained block encryption mode (where one block of encrypted data incorporates the prior block of encrypted data) we’re left with a problem regarding the first block, which is where the IV comes in.

If you had no IV, and used chained block encryption with just your key, two files that begin with identical text will produce identical first blocks. If the input files changed midway through, then the two encrypted files would begin to look different beginning at that point and through to the end of the encrypted file. If someone noticed the similarity at the beginning, and knew what one of the files began with, he could deduce what the other file began with. Knowing what the plaintext file began with and what it’s corresponding ciphertext is could allow that person to determine the key and then decrypt the entire file.

Now add the IV – if each file used a random IV, their first block would be different. The above scenario has been thwarted.

Now what if the IV were the same for each file? Well, we have the problem scenario again. The first block of each file will encrypt to the same result. Practically, this is no different from not using the IV at all.

So now let’s get to your proposed options:

Option 1. Embed hard-coded IV within the application and save the key in the key file.

Option 2. Embed hard-coded key within the application and save the IV in the key file.

These options are pretty much identical. If two files that begin with the same text produce encrypted files that begin with identical ciphertext, you’re hosed. That would happen in both of these options. (Assuming there’s one master key used to encrypt all files).

Option 3. Save both the key and the IV in the key file.

If you use a random IV for each key file, you’re good. No two key files will be identical, and each encrypted file must have it’s key file. A different key file will not work.

PS: Once you go with option 3 and random IV’s – start looking into how you’ll determine if decryption was successful. Take a key file from one file, and try using it to decrypt a different encryption file. You may discover that decryption proceeds and produces in garbage results. If this happens, begin research into authenticated encryption.