Take the 2-minute tour ×

I've seen that encrypting an image with AES-CBC then calculating the HMAC-MD5 value for authentication is a somewhat common and sound way to secure data. Alternatively, can I just calculate the CRC of the data, and then encrypt the data+CRC with AES-CBC?

I am concerned about a ciphertext-only attack modifying the data and that data then being decrypted and executed/processed. Can I assume that it is unreasonably difficult to maliciously modify encrypted data in a way that results in the same CRC or modifies the encrypted CRC to match? If that assumption can be made, then is it necessary to also do an HMAC-MD5 calculation of the encrypted data?

share|improve this question

migrated from stackoverflow.com Apr 24 at 16:01

This question came from our site for professional and enthusiast programmers.

It is actually completely trivial to modify data without affecting its CRC, because CRC is not cryptographically secure. So the answer is yes. –  ntoskrnl Apr 23 at 17:57
@ntoskrnl Thanks for the response! Is that still true when the data and the CRC itself are both ciphertext and the attacker only has access to the ciphertext? –  Trevor Apr 23 at 18:40
ntoskml's link is good, I'd just like to emphasize one of the items mentioned there: AES-GCM. It's more efficient than AES-CBC (especially with modern Intel CPUs) and offers the integrity requirements you're looking for built in. Unless you've got a good reason to stick with AES-CBC, I'd strongly recommend using AES-GCM. –  Mike Apr 23 at 20:22
Also, this hasn't mentioned yet, but consider MD5 dead. It has been catastrophically broken for many years now, and should no longer be used in any cryptosystem. –  Stephen Touset Apr 24 at 20:45

2 Answers 2

up vote 2 down vote accepted

In crypto, we like designs that are secure in (most) all use cases. There is a use case of your proposal that is trivially insecure.

Consider the AES cipher run in a stream-like mode (e.g., CTR). Due to linearity of CRC (i.e., $CRC(X\oplus Y\oplus Z)=CRC(X)\oplus CRC(Y)\oplus CRC(Z)$ and the malleability property of stream ciphers, it is very easy to modify the plaintext and then change the CRC so that it will still be correct.

I don't know if non-stream-like modes (e.g., CBC) have issues with your proposed design, but the fact that some modes do should steer people away from it.

So where we are is, the proposal is shown to be trivially insecure for a number of modes. I don't know if it is secure for certain other modes or constructions. So, yes, HMAC (or some other MAC) is necessary even though a CRC of the data is encrypted. In other words, CRC (even though it is encrypted) is not a good MAC.

P.S. you may find this question interesting.

share|improve this answer
nb: I should note that Mike is NOT saying CRC is a valid MAC! –  figlesquidge Apr 24 at 16:44

No, because in CBC mode, changes to a block of the ciphertext only affect the ciphertext locally.

Also, if data+CRC pads to only one block then xoring the leftmost part of the IV with a string of length len(data+CRC) will cause the output of CBC decryption to be xored by the same string.

Since CRC is linear, it follows that using your proposal with short messages is "xor-malleable", like the one-time pad.

share|improve this answer

Your Answer


