问AES - CCM，为什么不在里面使用CMAC而不是CBC-MAC？

EN

AES - CCM，为什么不在里面使用CMAC而不是CBC-MAC？

因此，在他们对802.11i (适用于WPA2 2)模式的最初建议中，怀廷、豪斯利和费格森给出的唯一理由是：

提出了一种计数器模式加密和CBC认证相结合的方案.这些模式已经被使用和研究了很长一段时间，具有很好的密码特性，没有已知的专利障碍。它们提供了良好的安全性和性能，无论是在硬件还是软件中实现。

因此，他们可能主要是在寻找一种模式，以满足他们当时的具体需求(没有专利，合理的快速和廉价，安全证明)，所以他们想出了这个相对简单的结构。

此外，“OMAC1 (2003年年第一次定义(PDF))”实际上是基于OMAC(2) (从2002年12月开始)的，它基于XCBC (从2000年开始，PDF格式)，它基于CBC-MAC。因此，由于CCM规范是从2002年1月开始的，它显然不能使用OMAC / CMAC。此外，XCBC在当时是已知的，但问题是需要3个键，这将把CCM的密钥大小从AES-128的128位增加到至少384位，这可能是一个不理想的结果。

但是如果CMAC更健壮，为什么不直接使用这个呢？

因此，我查看了规范，而CMAC实际上并不更健壮。CBC本身就是一个没有前缀的PRF (因此也是一个MAC).因此，如果不允许消息块序列成为彼此的前缀，那么就会得到一个安全的MAC。

在CCM中克服这一弱点的方法是将消息的长度编码到CCM的第一个输入块中，这样就没有两个长度不同的消息可以相互前缀，因为初始块总是不同的。CMAC克服这一问题的方法是通过XORing将一个常数秘密放入最后一个输入块，这样敌手实际上不知道CMAC的完整输入，因此如果不猜测依赖密钥的秘密常量，就无法找到任何前缀。

因此，正如您所看到的，在安全性方面，CCM的CMAC和CMAC在它们的属性上是相当等价的。唯一的缺点是，对于CCM，您需要提前知道消息长度，这有时是不方便的。

奖励:实际上，我认为消息长度的前置对于CCM来说是不必要的。这是因为CCM已经需要一个尊重安全的对手(否则CTR组件会严重崩溃)，所以保证每个CBC-MAC调用的第一个块是不同的，因此没有两个输入可以作为彼此的前缀。

还请注意，更流行的GCM破坏程度至少与此CCM变体一样严重，因为它泄漏了秘密身份验证密钥.