Is there any way an encrypted file using AES-256 could be modified without alerting the file owner, ie., so it can still be decrypted with the same key?

I know that without an initialization vector blocks in a cipher-text can be deleted, moved, duplicated etc. (am I right?) without detection. Using an initialization vector should preclude that attack, but are there any others?

Does the cipher-text need to be signed in order to ensure that it is unchanged?

3 Answers 3



This is an issue with any crypto system that does not protect integrity, such as with a signature or hmac. You see, encryption and decryption are just mathematical operations. You can always perform a mathematical operation on a blob of binary data, and will always get a result. Encrypting an decrypting operations do not error out because the data is modified.

The specific impact of modifying the ciphertext depends upon the mode of operation and the data modified. There is a famous attack where twiddling a bit in the old ATM (automated teller machines) protocol protected by DES would change the value of a transaction - deposit an unknown number of dollars instead of the amount you typed. The attacker wouldn't know what the result would be, but the attacker would deposit a small amount of money and the system would have a large max value, so odds were that a 'random' change to the amount would result in a larger deposit.

Swapping blocks and the other attacks you reference are intended for known meaningful changes. The root cause is still the same - lack of protecting the integrity of the message.

Now, there are a few exceptions to this, in the form of GCM, XST and a couple other newer encryption modes. These modes include the integrity check as part of the algorithm, instead of requiring you to implement an integrity check, yourself.

The initialization vector makes two values encrypted with the same key encrypt to different values. Without the IV, when you reuse keys and resent the 'same' message you would get the same ciphertext.

  • Do you have a source on the ATM attack? I can't seem to find anything on it.
    – Jane Panda
    Sep 18, 2015 at 13:01
  • @Bob it's been years since I learned about it, and I learned about it when the Web was still very, very young. It could have been one of dozens of security books, presentations, conversations, papers, etc.
    – atk
    Sep 19, 2015 at 2:01
  • That's a shame, I was hoping to use it as an example in an essay I'm working on. Thanks for the response though!
    – Jane Panda
    Sep 19, 2015 at 2:27

Encryption algorithms like AES by itself does not ensure data integrity. That property is provided by a MAC like HMAC.

It is completely possible that an attacker can tamper with the ciphertext without being detected if you do not properly apply a MAC on it.


Assuming the key isn't stolen/broken/compromised, the answer depends on what mode was used to apply encryption.

If a weak or inappropriate mode was used (for instance ECB), then an attacker has free rein in using the various cyphertext blocks. He can freely remove, reorder and reuse blocks (including from previous streams using the same key) with the encryption layer being the wiser.

With other block modes of operation, the same isn't necessarily possible. If a proper (i.e. unique) initialization vector is chosen, for instance, even CBC is resilient to any of these manipulations.

Note that, in any case, none of the above will prevent a full replay attack (when the attacker replay the entire encrypted message) on it's own any many are vulnerable to data truncation. That is why it is advisable to insert a time stamp or serial number and some for of CRC with the cleartext message: it will allow the recipient to protect himself against replay and truncation attacks.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .