2
$\begingroup$

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?

Improve this question
$\endgroup$
5
  • 3
    $\begingroup$ It is actually completely trivial to modify data without affecting its CRC, because CRC is not cryptographically secure. So the answer is yes. $\endgroup$
    – ntoskrnl
    Apr 23, 2014 at 17:57
  • $\begingroup$ @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? $\endgroup$
    – Trevor
    Apr 23, 2014 at 18:40
  • 3
    $\begingroup$ 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. $\endgroup$
    – Mike
    Apr 23, 2014 at 20:22
  • $\begingroup$ 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. $\endgroup$
    – Stephen Touset
    Apr 24, 2014 at 20:45
  • 1
    $\begingroup$ @StephenTouset Even if MD5 is broken, HMAC-MD5 is much more secure, due to how HMAC works. See crypto.stackexchange.com/a/9340 $\endgroup$
    – Arnaud Bouchez
    Oct 14, 2016 at 9:27

2 Answers 2

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ nb: I should note that Mike is NOT saying CRC is a valid MAC! $\endgroup$
    – Cryptographeur
    Apr 24, 2014 at 16:44
1
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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