# Using only 4 Bytes of AES-CMAC

if i calculate a AES_CMAC for 64 Bytes, i get a 16 Byte CMAC.

Is it ok to use only the first 4 Bytes for authentication?

Can i assume that if the first 4 bytes are correct, the other bytes must be ok too?

Thank you!

With AES_CMAC, tag truncation acts like you would expect; if an attacker generates a message and a random tag, then they have a $2^{-32}$ (or one in 4 billion chance) of happening to pick the correct random tag (and getting the message accepted), and with AES_CMAC, there's nothing they can do to improve on that.

Is a $2^{-32}$ success probability per attempt by the attacker acceptable? Well, that depends on what your authenticating (and the cost to you of accepting an invalid message); in some scenarios, that might be quite acceptable, in others (e.g. doing financial transfers) it might not.

• In particular, without some kind of rate limiting in place on the recipient's side, a $2^{-32}$ forgery rate is definitely too high. Even if the legitimate sender only transmits, say, one message per second, that doesn't mean the attacker can't generate $2^{32}$ messages, each with a different MAC, and blast them at the recipient until one gets accepted. On a modern computer and a decently fast network, that may take them less than a second. Jan 25, 2017 at 19:46
• But still, there are applications where a 32-bit mac is acceptable.
– K.G.
Jan 25, 2017 at 20:30
• Rate limiting is a good point, but "less than a second" is an exaggeration, no? Assuming the message and MAC can be compressed into 1 bit, that still requires >4 gigabit per second to achieve such timings. Jan 25, 2017 at 21:42

No, you cannot assume that if the first four bytes are correct, the other bytes are correct, too.

Truncating the CMAC tag to four bytes means that an adversary will be able to forge a valid tag value (without knowing the secret key) with a success probability of about $2^{-32} \approx 4\cdot 10^{-9}$. This value is usually considered in most threat models as being way too large, i.e., not secure enough.