5

Given a 128-bit key used for authentication based on AES-CMAC, the NIST 800-38B recommendations suggest at least two criteria for a good key cryptoperiod:

  1. after 'MaxInvalids' error messages the key should be retired (considering the MAC truncation and the accepted Risk in appendix A);
  2. the key should be changed to limit its message span (e.g. $2^{48}$ usages for AES-128).

My question is: should the second criterion be considered if I have MAC truncation? In my scenario, I'm assuming that the attacker can only see truncated MACs (suppose $30$ bits after truncation). Since I'm using truncation, and this criterion is made to avoid attacks based on detection of a pair of distinct messages with the same MAC before its truncation, should I still consider this criterion? If yes, should the limit still be $2^{48}$ or is it affected by the truncation?

UPDATE

The scenario is: only truncated MACs are sent to a limited-bandwidth network, and the attacker has access to the network. Considering Elias answer I removed the assumption that the attacker sees only truncated MACs, which is not meaningful. So, if we remove this assumption, do I have to shorten the cryptoperiod to consider $2^{15}$ (truncated MAC), or I can just consider $2^{64}$ (entire MAC)?

gentooise
  • 254
  • 1
  • 9

1 Answers1

1

Yes, truncated MACs influence the cryptoperiod.

First of all, I cannot really think of any case where it makes sense to assume that the attacker only sees a truncation of the MAC if that isn't what is actually used in the system! And if you actually truncate your MACs to 30 bits you will probably have collisions after $2^{15}$ message blocks. So you definitely need to reduce the cryptoperiod.

On the other hand you're saying an attacker can only see 30 bits of the MAC because you are truncating it. Let us assume that you are still using the full MAC and that this makes sense in your scenario for some reason.

This in itself doesn't change the attackers position significantly:

  • Exhaustively searching for the correct key becomes more complicated because now the given 30 bits of the MAC might match but it might still be the wrong key. However there are $2^{128}$ possible keys and by the birthday paradox a MAC collision will probably occur after about $2^{64}$ message block. So this is the more plausible target anyway.
  • When a collision occurs the attacker can now not readily detect it anymore because only parts of the MAC are visible to him. On the other hand it will potentially be easy to submit fake queries to validate potential collisions and the probability for a collision doesn't change when the attackers view is truncated.

So in this case it would be fine to keep the values but I would love to hear how this makes sense.

Elias
  • 4,933
  • 1
  • 16
  • 32