Reusing IV in AES for encrypting file

Question

Everyone says that you shouldn't use the same IV and Key.

• Is it safe to use the same IV and Key on only one file. EDIT: I will be using CBC or CFB encryption modes so the IV will be updated based on previous block.
• Is it safe to use the same IV (EDIT: Same first IV, which will then be updated with each block.) each time I access and add data to the file. Each time this happens, there will only be one encrypted file so multiple files with same IV and Key will not happen.

Edit: The program using the file will just add data to the end of the file. From what I could find, this will not change the encryption of the first sections of the file, as the IV is changed based on what was done in the previous block. Is that correct?

Edit 2: For simplicity, let's say this is a log file that I want encrypted for some reason. I want to be able to add on to the end of this log while not needing new key/IV. Since it is the end of a file, I was thinking while decrypting, I will have the next IV for CBC or CFB and use it to begin encrypting the next entry. As for mutability, I will never have a reason to change anything in the middle of the log/file, only to add on to the end. I don't know how that lines up with cryptographic mutability/immutability, but that is what I want to do.

Final: I am using CBC. At the beginning of every line I have a new IV (first 16 bytes are the IV) and the rest of the line is encrypted using that IV. Thanks for all the pointers. If anyone sees any major thing wrong with this, please let me know.

Answer 1

Everyone says that you shouldn't use the same IV and Key.

Correct. They are saying that because any deterministic encryption leaks some information about the message. That can be a lot of information such as with CTR or CFB mode, or a relatively small amount when it comes to CBC if we assume that the attacker cannot perform a chosen plaintext attack.

• Is it safe to use the same IV and Key on only one file. EDIT: I will be using CBC or CFB encryption modes so the IV will be updated based on previous block.

That depends on how the file is used and what kind of attacks are possible. For CBC mode it would indicate which block would be changed of the file. For CFB mode it may and likely will lead to complete loss of confidentiality of the plaintext in the updated blocks.

For this the attacker must of course be able to see the differences of the files. If the attacker only gets to see one version of the file then this issue goes away and there is nothing to attack - it would regress into normal encryption using one IV.

• Is it safe to use the same IV (EDIT: Same first IV, which will then be updated with each block.) each time I access and add data to the file. Each time this happens, there will only be one encrypted file so multiple files with same IV and Key will not happen.

You can basically see one file in many versions as multiple files. But it also means that a lot of information about those files is known, which makes attacking the files easier rather than harder.

Edit: The program using the file will just add data to the end of the file. From what I could find, this will not change the encryption of the first sections of the file, as the IV is changed based on what was done in the previous block. Is that correct?

Yes, that is correct. However, for CBC you're now violating the rule that, to an attacker, the IV must be unpredictable. As the vector for the new ciphertext is now known in advance, known plaintext attacks are possible. So if your attacker can somehow influence what you are encrypting, you're still vulnerable. This is likely the case for, for instance, log files as they depends on program state, and program state can often be influenced by an attacker.

So in this case CFB mode, which is a stream cipher, is better up to the job. CFB mode also uses the previous ciphertext block, but this one is encrypted before being XOR'ed with the plaintext, so the attacker cannot perform the chosen plaintext attack that is available for CBC mode.

Edit 2: For simplicity, let's say this is a log program that I want encrypted for some reason. I want to be able to add on to the end of this log while not needing new key/IV. Since it is the end of a file, I was thinking while decrypting, I will get the next IV for CBC or CFB and use it to encrypt the next entry. As for mutability, I will never have a reason to change anything in the middle of the log/file, only to add on to the end. I don't know how that lines up with cryptographic mutability/immutability, but that is what I want to do.

It is probably better to encrypt each log in the file separately, e.g. using a counter or SIV mode. As you need to synchronize access to the log file writes you may as well use a nonce. The only thing that is tricky in that regard is to prevent reuse when the application needs to be restarted, which could mean losing the state. You may also use the UTC log time if the time source is considered secure enough (using local time is not a great idea, because it may repeat once a year if or when daylight savings are applied or time zones are changed).

---

If you're going to use any mode of operation on the whole file instead of the log entries then CTR (counter) mode offers the best properties: you can encrypt/decrypt from any offset without considering the value of the previous ciphertext block, you don't need padding and you don't need an unpredictable IV.

But beware that if you ever reuse the counter for a specific block that you have the same issue in CTR mode as for CFB mode: almost certain loss of confidentiality. You only want to use CTR mode if you can indeed only add to the file.

You may need to program CTR mode yourself if your API doesn't allow you to specify an offset, and implementing cryptography is dangerous in itself.

Answer 2

You aren't telling us exactly what you plan to do, but plenty enough that we can tell you: no, just no. The first mistake you're making is that you're talking about "files" in a way that's worrisome in the context of cryptography. In modern programming parlance, cryptography by default deals with immutable values, not with mutable objects. But when you talk about "files" in this question it is evident that at least on some occasions you mean a mutable object, one into which different values are written and overwritten at different points in time.

So the cryptographic requirement that you never use the same key+IV pair to encrypt more than one value then applies not to the file as a unit, but to each operation that encrypts a value to be written into the file.

• Is it safe to use the same IV and Key on only one file.

Generally, no. There are special cases where it's safe, if for example you're using files in a strict write-once never-modify manner, where you're only ever writing to a file at the time you create it. But that's not what you're proposing to do:

• Is it safe to use the same IV each time I access and add data to the file. Each time this happens, there will only be one encrypted file so multiple files with same IV and Key will not happen.

No. Each time you wrote to this file you'd be encrypting a different value with the same key and IV, and that violates the IV reuse condition. Note that the likely practical consequence of this is that your file format will need to be structured to support encryption—for example, you might need to build some notion of "data block" within the file format, so that each data block can be encrypted with a different IV, and the metadata necessary to identify block boundaries and their IVs is present.

The program using the file will just add data to the end of the file. From what I could find, this will not change the encryption of the first sections of the file, as the IV is changed based on what was done in the previous block. Is that correct?

It sounds like you're looking at some materials that describe CBC mode encryption. This idea that the IV changes based on what was done in the previous block is likely not something that happens automatically, it'd be something you'd have to understand and implement—which is an error-prone and risky undertaking. CBC also doesn't provide authenticated encryption, which means that you likely would need to add some sort of message authentication, which makes the whole thing even harder to get right—for example, the recent Efail vulnerability on GPG and email clients hinges on this.

Whatever you're thinking of doing is likely a minefield.

Answer 3

will not change the encryption of the first sections of the file, as the IV is changed based on what was done in the previous block

In fact you are righ. Have a look at mode of operations how IV is used. Important thing is that a block of data is encrypted to something unpredictable even you'd know how the same plaintext block was encrypted before.

So if you add data to a file while updating IV accordingly, you are enabling to decrypt the file with a single IV (I assume that's your intention) , while the added blocks should have different IV themselves.

So when we are talking about different IV, it is different IV for each encryption block. For some modes it must be even unpredictable (e. g. cbc)