Use cases for CMAC vs. HMAC?

HMAC was there first (the RFC 2104 is from 1997, while CMAC is from 2006), which is reason enough to explain its primacy. If you use HMAC, you will more easily find test vectors and implementations against which to test, and with which to interoperate, which again explains continuedprimacy. Being the de facto standard is a very strong position.

On many embedded systems, one may expect HMAC to be faster than CMAC, because hash functions are usually faster than block ciphers. This is not true if the platform includes some hardware optimization for a specific block cipher (e.g. dedicated AES opcodes), or if the messages are short (HMAC has the same asymptotic cost as hashing, but also a fixed overhead), or if you do something stupid like selecting a slow hash function as basis for HMAC (e.g. Whirlpool). As with all performance things, actual measures are needed to reach any kind of definitive conclusion.

If you need to both encrypt and MAC, then the smart thing to do is not HMAC or CMAC, but rather to use an authenticated encryption mode which will do both properly, simultaneously, and at a lower cost (or at least so it is hoped). Usual candidates are EAX and GCM. There is an ongoing open competition for finding new, better AE modes.

 

HMAC首先出现在那里（RFC2104是1997年的，而CMAC是2006年的），这足以解释其重要性。如果您使用HMAC，您将更容易找到测试向量和实现，根据这些向量和实现进行测试，并与哪些向量和实现进行互操作，这再次解释了持续的优先性。作为事实上的标准是一个非常强大的地位。              在许多嵌入式系统中，人们可能期望HMAC比CMAC更快，因为哈希函数通常比块密码更快。如果平台包含特定块密码的某些硬件优化（例如专用的AES操作码），或者消息较短（HMAC与散列具有相同的渐进成本，但也有固定开销），或者如果您做了一些愚蠢的事情，例如选择一个慢散列函数作为HMAC的基础（如漩涡）。与所有的性能一样，需要实际的度量来得出任何类型的确定结论。              如果您同时需要加密和MAC，那么明智的做法不是使用HMAC或CMAC，而是使用一种经过身份验证的加密模式，该模式既能正确地、同时以较低的成本（或者至少希望这样做）。通常的候选人是EAX和GCM。在寻找新的、更好的AE模式方面，存在着持续的公开竞争。