CMAC 为什么选择 K1 和 K2
http://en.wikipedia.org/wiki/CMAC
http://www.rfc-archive.org/getrfc.php?rfc=4493
有两个钥匙 K1 和 K2。除了消息 1 与 10^127（1 和 127 个零）不同之外，还有其他原因吗？
如果消息携带长度（长度也是 CMAC-ed 的惠特消息），仅使用一个随机生成的 K 是否存在任何安全弱点？
http://en.wikipedia.org/wiki/CMAC
http://www.rfc-archive.org/getrfc.php?rfc=4493
There are two keys K1 and K2. Are there any other reasons, beside that messages 1 differs from 10^127 (1 and 127 zeroes)
If message carries length (and length is also CMAC-ed whit message), are there any security weaknesses using only one randomly generated K?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，AES-CMAC 中实际上只有一个密钥 K - 这是您必须生成的唯一一个密钥，以解决您的最后一个问题，并且在规范中明确说明了这一点：
您的另一个问题 - 为什么我们需要从 K 生成 K1 和 K2 - 有点难以回答，但实际上有一个非常简单解释：消除消息认证中的任何歧义。
为了说明这一点，假设我们从 wiki 文章中获取二进制密钥：K1 = 0101 和 K2 = 0111。现在让我们来看看消息 M = 0101 011。因为M不是由完整的块（三位而不是四位）组成，所以我们必须填充它。现在我们有 M' = 0101 0111。
要为此消息生成 MAC，我们只需对密钥进行异或：
如果我们在两种情况下都使用了 K1，则我们有以下过程：
这一切都很好，但是请注意当我们尝试为 M'' = 0101 0111（即未填充的消息）生成 MAC 时会发生什么M'' 与填充消息 M' 相同）。
我们从两条不同的消息生成了相同的 MAC！使用第二个密钥（它具有一些数论属性，可以防止它与K1有问题地“相似”）可以防止这种歧义。
First of all, there's really only one key K in AES-CMAC - it's the only one you have to generate, to address your last question, and that's stated explicitly in the spec:
Your other question - why do we need to generate K1 and K2 from K - is a little bit harder to answer, but there's actually a very simple explanation: to eliminate any ambiguity in the message authentication.
To illustrate, supposed we take the binary keys from the wiki article: K1 = 0101 and K2 = 0111. Now let's play with the message M = 0101 011. Because M is not made up of full blocks (three bits rather than four), we have to pad it. Now we have M' = 0101 0111.
To generate the MAC for this message, we just have to XOR our keys in:
If we had used K1 in both cases, then we'd have the following procedure:
This is all fine and good, but watch what happens when we try to generate a MAC for M'' = 0101 0111 (that is, an unpadded message M'' identical to the padded message M').
We've generated the same MAC from two different messages! The use of the second key (which has some number-theoretical properties that prevent it from being problematically "similar" to K1) prevents such an ambiguity.
我不认为这与已知明文攻击有关，并且我不同意对称密码容易受到它们的影响。密码安全的条件之一是它在 KPA、CPA（选择明文攻击）和 CCA（选择密文攻击）下是安全的。
除非我不明白你的问题，否则你仍然需要两个子项。当块不是完整块时使用 K2。
。
K1 和 K2 不是随机生成的，而是从 K 派生出来的。您是否有理由不想生成这些子密钥？
基于链接模式的认证码存在许多弱点。 CBC-MAC 已证明仅对于固定大小的消息是安全的。对于填充了最后一个块的可变长度消息，安全性完全失败。
您可以阅读 XCBC 论文来了解攻击是如何进行的：
“作为一个简单的示例，请注意，给定单块消息 X 的 CBC MAC，比如说
T = CBCEK(X)，对手立即知道两块消息 X || 的 CBC MAC (X^T)
因为这又是 T。”
[1] http://www. cs.ucdavis.edu/~rogaway/papers/3k.pdf
I don't believe it has to do with known-plaintext attacks, and I disagree with symmetric ciphers are susceptible to them. One of the conditions of a cipher being secure is that it is secure under KPA, CPA (chosen-plaintext attacks) and CCA (chosen-ciphertext attacks).
Unless I am not understanding your question, yes, you still need both subkeys. K2 is used when a block is not a complete block.
.
K1 and K2 are not randomly generated, but are derived from K. Is there a reason you do not want to generate these subkeys?
There are a number of weaknesses in authentication codes based on chaining modes. CBC-MAC was provably secure only for fixed size messages. The security completely fails for variable length messages where the last block is padded.
You can read the XCBC paper to see how the attack works:
"As a simple example, notice that given the CBC MAC of a one-block message X, say
T = CBCEK(X), the adversary immediately knows the CBC MAC for the two-block message X || (X ^ T)
since this is once again T."
[1] http://www.cs.ucdavis.edu/~rogaway/papers/3k.pdf
我认为对称密码很容易受到已知明文攻击，至少在过去是这样。由于您执行了一部分明文（填充模式），因此您不想泄漏有关密钥的信息。如果您可以通过这种方式提取密钥的某些位，则可以对最后一个块进行暴力攻击，但所有其他块仍然安全（至少在这种 KP 攻击下），因为它们已通过 K1 加密。
为了克服同样的问题，基于块的密码通常以各种模式运行，请参阅：
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation。不知道为什么CMAC的设计中没有考虑这个显而易见的解决方案。
I suppose symmetric ciphers are susceptible to know-plaintext attacks, at least they have been in the past. And since you do a portion of the plaintext (the padding pattern) you don't want to leak information about your key. If you can extract some bits of the key that way you can brute-force attack the last block but all other blocks remain secure (under this KP attack at least) since they have been encrypted via K1.
To overcome the very same problem, block-based ciphers usually operate in various modes, see:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation. Don't know why this obvious solution hasn't been considered in the design of CMAC.