# How to truncate MAC to 32 bit?

I want to use MAC as an additional protection of UDP-server from DoS attacks. I prefer to keep MAC as short as possible and I assume 32 bit is good enough for this purpose.

I'm going to make it based on some well-known MAC (e.g. KECCAK Message Authentication Code)
Is it bad idea to use CRC32 of this MAC?
Or it is better to use first 4 bytes of MAC?

## 3 Answers

The common practice is to use the four leftmost bytes of the MAC. I would not use the CRC32 over the MAC. It's not more secure and if you're unlucky it is less secure. Besides that it is an unnecessary operation.

Note that 32 bits doesn't give you much security; I would only use it for realtime integrity / authentication or in case there are other reasons that prevent brute force attacks.

• What do you mean when speaking about brute force attack? "Generate a lot of messages with random keys and some keys will be correct?" – edo1 Jul 17 '17 at 18:57
• Just create a lot of identical messages and vary the tag. With enough messages you're going to hit a correct tag in the end. Varying the key doesn't make sense. You would get identical tags, and finding the right key is impossible anyway (if the key size is large enough). – Maarten Bodewes Jul 17 '17 at 19:03
• While I wouldn't recommend the CRC32 over the MAC, it can't be less secure if computed correctly; it it was, that attack on the CRC32-reduced version of the MAC would allow an attack on the MAC. – fgrieu Jul 17 '17 at 20:28

Don't truncate one-time-macs (e.g. GHash or Poly1305) because a successful forgery reveals part of the key. Poly1305 might be fine, if the receiver ensures nonce uniqueness and you derive the complete Poly1305 key from the nonce (i.e. both the multiplier and the mask).

On the other hand, truncating HMAC or MACs based on CBC-MAC (e.g. CMAC) is fine (I think it even avoids the prefix-weakness of plain CBC-MAC).

I would not consider CRC32, it's unkeyed and I can't think of an easy to build a secure MAC from it (GHash is probably the closest thing to a secure CRC).

I recommend going with a truncated HMAC. It's designed to be a PRF and since truncated PRFs are still PRFs, you can be certain that it has no weaknesses beyond the obvious $2^{-32}$ forgery chance.

• KMAC as posted in the question would also be secure. – Maarten Bodewes Jul 17 '17 at 18:40
• @MaartenBodewes KMAC was the keyed keccak mode? (Not a fan of using such a generic name, for such a specific algorithm) – CodesInChaos Jul 17 '17 at 18:43
• That's the only KMAC that I know of anyways :) – Maarten Bodewes Jul 17 '17 at 18:43
• @edo1 In that case it's a harmless over-complication. CRC32(KMAC(msg)) offers no advantages over just truncating KMAC(msg) but it doesn't introduce any weaknesses either. – CodesInChaos Jul 17 '17 at 20:44
• It's worth noting that network traffic authentication is one of the use cases that SipHash was designed for. – Luis Casillas Jul 17 '17 at 20:56

Al least with RNG if you want to short the value of generated number, is a bad idea just taking some bits out of the original number. It happens that the strength of the generator weakens. For instance with a Linear and Congruential Generator if you take just four bits out of the main generator of 32 bits, it will generate a sequence of just 2^4 values that repeats again and again.

The way we fix this issue is by performing a modulus operation of the original value of the generator with a number of the size we want to get. With this approach the strength of the generator is kept.

For your particular case you should: MinimalMAC = MAC%2^32

A possible problem that could arise is to have the tools to perform the modulus operation with large numbers but is you are using libraries such a openSSL, it will give you the functions to do that.

• So you offer use last 4 bytes instead of first 4 bytes. Why that makes the difference? – edo1 Jul 30 '17 at 12:41
• I said taking just the 4 bytes would weak the strength of the algorithm. I mean to resize the full MAC to 32 bits using a modulus operation. – Luis Orantes Jul 31 '17 at 17:33
• MAC%2^32 is equal to last 4 bytes of MAC (for little-endian) – edo1 Jul 31 '17 at 21:10