Why should one use a cypher-based message authentication code (CMAC) instead of symmetric encryption and CRC?

What are advantages/disadvantages for using a CMAC that proofs the integrity and authenticity of a message but doesn't encrypt the payload itself? Why should it be used instead of symmetric encrypted payload and CRC (CRC is encrypted as well)? This could also proof authenticity, integrity AND confidentially.

From my point of view the only reason is when one has a huge amount of data, encryption takes too long and confidentially is not required. But what about short message? In both situations the same key is used and using a symmetric encryption fulfills the security goal confidentially...

• CRC has no authentication component, anyone can modify the payload and recompute the CRC. This section of the CRC wiki page pretty much answers your question. – Marc Sep 12 '20 at 16:42
• @Marc: do you want to make that the answer? I can't think of anything to add... – poncho Sep 12 '20 at 16:46
• @poncho: I'm not sure it's the right answer. After a second reading of the question, it sounds like OP is asking why we couldn't use $AES(msg) | AES(CRC)$. – Marc Sep 12 '20 at 16:56
• @Marc: if $AES$ in counter mode, well, we both know that won't work... – poncho Sep 12 '20 at 17:01

1 Answer

The main reason to use a proper cryptographic authentication code is to ensure the very properties you listed. Your proposal of ciphertext and CRC (encrypted or not) fails to provide those.

Let's consider three possible arrangements of data transmission with CRC:

Plaintext message and CRC:

CRC (Cyclic Redundancy Check) is meant to detect errors in transmission or storage.

It is a straightforward algorithm with a single input (the message) and a single output (the CRC code). As such it cannot provide protection against willful modification of the data as anyone can compute the new CRC code.

This means we would need to ensure the CRC cannot be manipulated. Let's take up your first proposal:

Encrypted message, plaintext CRC:

One big problem here: CRC is not a cryptographic hash function, nor was it ever supposed to be. It has too many chances of leaking information about the plaintext.

The properties in the next section also mean that they can modify the encrypted message AND properly modify the CRC.

Encrypted message and CRC:

One notable property of CRC is that $$\operatorname{CRC}(x \oplus y) = \operatorname{CRC}(x) \oplus \operatorname{CRC}(y)$$.

block ciphers modes operate using the XOR operator over a mix of plaintext, key, IV, previous ciphertext, etc...

In some cipher modes, XORing the ciphertext is the same as XORing the plaintext. For example, the counter block cipher mode boils down to: $$\text{ciphertext} = \text{plaintext} \oplus \operatorname{AES}(IV)$$

To fake the message, I can compute $$\text{diff} = \text{plaintext} \oplus \text{desired_plaintext}$$ and return the following:

• new ciphertext: $$\text{ciphertext} \oplus \text{diff}$$
• new encrypted CRC: $$\text{encrypted_crc} \oplus \operatorname{CRC}(\text{diff})$$

I have effectively modified the message and its CRC without having to break the encryption.

You can find further reading and references in the data integrity section of the CRC wiki page.

[EDIT: credit goes to Maarten Bodewes] CRC size limitations:

CRC's are generally limited to 32 bits (although 64 bit CRC's have been defined), which is not enough to provide 128 bits security. Just trying in the order of $$2^{32}$$ random messages (or separate connections) would give you a chance of ~0.63 to get one right. That's simply to high of a chance even if CRC could not be attacked by other means.

Now it is possible to create a MAC by performing a relatively fast operation over blocks of 128 bits / 16 bytes and then encrypt the result. These kind of techniques are used for GMAC (in AES-GCM) and Poly1305 used within ChaCha20/Poly1305 used in - for instance - TLS 1.2 and 1.3. These still rely on a block cipher for security, but the block cipher is only used once or twice instead of for each block of the message.

Note that GCM and ChaCha20/Poly1305 operate on the ciphertext rather than the plaintext, but that can be considered an implementation detail. Generally you want to verify message authenticity before decryption.

You may also be interested in one of the secure OCB modes (1 & 3) which integrates both authentication and encryption, doing away with any additional (computationally intensive) operations on the data.

• It is quite possible to keep the same CRC but have a different message. If we assume that CRC-32 is used then it can only say that the message is in one of the $2^{32}$ distinct sets. This is better than too many chances... Also, it might possible that if a stream cipher is used than we can modify the ciphertext and the CRC so that they are both valid. – kelalaka Sep 12 '20 at 19:12
• Note that using CRC as an authentication code was one of the many major flaws of WEP... – SEJPM Sep 13 '20 at 10:00
• @SEJPM major flow or intentional flaw? – kelalaka Sep 13 '20 at 19:18
• You may want to clarify that using a bigger CRC (e.g. a 1024-bit one) would in fact not solve the problem as all the above problems still stand and only the direct brute-forceability gets a bit worse. – SEJPM Sep 14 '20 at 14:43
• Going a step back, CRC and hash functions are booth mathematical functions but CRC could cause the risk that one could modify an encrypted message and its included CRC that can not get detected? – MaMa Sep 17 '20 at 21:40