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.