CMAC为什么是k1和k2

我不认为这与已知的明文攻击有关,我不同意对称密码容易受到攻击。密码安全的条件之一是它在KPA、CPA(选择明文攻击)和CCA(选择密文攻击)下是安全的。

除非我不理解你的问题,是的,你仍然需要两个子项。k2用于块不是完整块的情况。 . k1和k2不是随机生成的,而是从k派生的。您不想生成这些子键有什么原因吗?

基于链接模式的身份验证代码存在许多弱点。cbc-mac仅对固定大小的消息是安全的。对于最后一个块被填充的可变长度消息,安全性完全失败。

您可以阅读xbc文件以了解攻击的工作原理:

“作为一个简单的例子,注意给定一个块消息x的cbc mac,比如 t=cbcek(x),对手立即知道cbc mac的两块消息x(x^t) 因为这又是T。”

〔1〕 http://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf

首先,实际上只有一把钥匙 K 在aes-cmac中,这是唯一一个必须生成的,以解决最后一个问题,这在规范中明确说明:

子键生成算法generate_subkey()采用密钥k,这是AES-128的密钥。

你的另一个问题-为什么我们需要生成 K1 和 K2 从 K -回答起来有点困难,但实际上有一个非常简单的解释:消除消息认证中的任何模糊性。

举例来说,假设我们从wiki文章中获取二进制键: K1 = 0101和 K2 = 0111。现在让我们来玩儿这个消息 米 = 0101 011。因为 米 不是由完整块(三位而不是四位)组成的,我们必须填充它。现在我们有 M’ = 0101 0111。

要生成此消息的MAC,我们只需在以下位置执行XOR键:

M'  = 0101 0111
K1  = 0101
K2  =      0111
MAC = 0000 0000

如果我们曾经用过 K1 在这两种情况下,我们都有以下程序:

M'  = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

这一切都很好,但是当我们尝试为 M’ =0101 0111(即未添加的消息 M’ 与填充邮件相同 M’ )

M'' = 0101 0111
K1  = 0101
K1  =      0101
MAC = 0000 0010

我们从两条不同的消息中生成了相同的Mac!第二个键的使用(它具有一些数字理论属性,可以防止它在问题上“类似”于 K1 )防止这样的歧义。

我认为对称密码容易受到明文攻击,至少过去是这样。而且,由于您执行了纯文本(填充模式)的一部分,所以不希望泄漏关于您的密钥的信息。如果你能以这种方式提取一些密钥位,你就可以强力攻击最后一个块,但所有其他块都是安全的(至少在这个kp攻击下),因为它们是通过k1加密的。

为了克服相同的问题,基于块的密码通常以各种模式运行,请参见: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation . 不知道为什么在CMAC的设计中没有考虑到这个明显的解决方案。