Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 Apr 24 '14 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 '14 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 '14 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 '14 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 '14 at 20:45
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 '14 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


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.