Does symmetric encryption provide data integrity?

Question

Let's say I have one server that encrypts a file with a symmetric key, e.g. AES-CBC, and sends it to clients that decrypt it. Does that provide data integrity when decrypted? Or is it possible for someone to tamper with the file while it's still encrypted, and later when the client decrypts it, produce a modified file?

I typically see data integrity and authenticity discussed in terms of using digital signatures or MAC, but never in the context of encryption. I've also seen benchmarks that show encryption being more expensive than hashing, but that's not my main consideration.

UPDATE

I tried an experiment, where I used the openssl tool in Linux to encrypt a file. Then, I tried modifying the file in various ways (changing a byte, deleting a byte, appending a byte). In every case, when I tried decrypting, I would get a "bad decrypt" message. The commands I used were:

openssl enc -aes-128-cbc -in test -out test.enc
openssl enc -d -aes-128-cbc -in test.enc -out test.dec

Answer 1

Symmetric encryption does not provides integrity. The amount of control that an attacker can have on encrypted data depends on the encryption type; and some specific details of some encryption modes can make the life a bit harder for the attacker if he wants to make surgical modifications. With CBC, the attacker can flip any bit he wishes, provided that he does not mind transforming a dozen other bytes into random junk.

There are recent encryption modes which combine symmetric encryption and checked integrity (with a MAC). These modes ensure both confidentiality and integrity. AES-CBC is not one of them. If you want an encryption mode with integrity, I recommend EAX.

Update: concerning your experiment: CBC is a mode where the source data length must be a multiple of the block cipher block length (16 bytes, for AES). Since an arbitrary input message may have any length, some padding is added: a few bytes, with specific contents such that they can be unambiguously removed upon decryption. In your case, OpenSSL is complaining that, upon decryption, it does not find a proper padding structure. However, if the attacker does not alter the last 32 bytes of the encrypted data, the padding will be undamaged, so alterations of all but the last 32 bytes will remain undetected. And even for the last 32 bytes, there are ways to evade detection with a not-so-small probability.

Answer 2

CBC-encryption does not provide data integrity. Here's why:

Fix some key k (unknown to the attacker). Let E(k,-) and D(k,-) be the bare encryption and decryption functions of some block cipher. Let p be some single block of plaintext. I'll denote XOR by +. After fixing some IV, we encrypt as follows:

c = E(k,p + IV).

Then, we send IV and c over the wire. To decrypt, we compute

p = D(k, c) + IV.

(Note that this is equivalent to the statement D(k,c) = IV + p.)

Now, suppose that an attacker knows a single plaintext/ciphertext pair. Let's denote them as p and (IV, c), as above. Now, suppose that the attacker would like to create ciphertext that will decrypt to some other plaintext block of his choosing -- say p'. I claim that (IV + p + p', c) decrypts to p'. Why?

Well, we just follow the decryption procedure above, replacing IV with IV + p + p'. We have

D(k,c) + (IV + p + p') = (IV + p) + (IV + p + p') = p'.

Amusingly, ECB-mode is not vulnerable to this issue (though I don't endorse its use either).

Answer 3

AES-CBC encryption does not provide integrity. Depending upon how it is implemented and used, it might happen to detect some accidental modifications to the ciphertext, but it does not defend against malicious tampering with the ciphertext.

Encrypting without authenticating is one of the most common mistakes in the use of cryptography. It has led to serious vulnerabilities in many systems, including ASP.NET, XML encryption, Amazon EC2, JavaServer Faces, Ruby on Rails, OWASP ESAPI, IPSEC, and WEP. See the previous link for more information.

The fix: You should either use an authenticated encryption scheme (not AES-CBC), like EAX, or you should use a message authentication code, like CMAC, in encrypt-then-authenticate mode.

If you are going to be implementing cryptography yourself, I encourage you to read the question here entitled Lessons learned and misconceptions regarding encryption and cryptology to help you avoid some of the most common mistakes. Using encryption without authentication is one of them.

Answer 4

Symmetric ciphers do not by themselves provide integrity because they do not detect malicious or accidental modifications to ciphertext; decryption will output something else than the original plaintext and unless this results in some protocol violation for the decrypted payload then you have an integrity problem.

The solution is to wrap plaintext inside packages which include data which can be used to validate the integrity of the package, typically a hash-based checksum (edit: keyed HMAC). This is what is done e.g. for Transport Layer Security.

Here is an example of a plaintext-protection scheme used in a Versile Platform secure byte transport protocol (disclaimer: I am involved in VP development).

Edit: I realized message-encapsulation is overkill for your scenario which involves a complete file, and so you are better off just adding a keyed MAC on the complete ciphertext. For package protected formats, as D.W. points out the details matter, and "checksum" should be performed as a keyed MAC.

Answer 5

If you include the plaintext, then I would say yes, using a symmetric key to encrypt something, where the receiver can decrypt it and compare it to the plaintext, provides data integrity.