Does symmetric encryption provide data integrity?

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.


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).


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.