您应该验证 ipsec 中的初始化向量吗？
根据 RFC4106，我正在尝试在传输模式下以 ESP 的形式实现 IPSEC，并在伽罗瓦/计数器模式下使用 aes。
我应该将初始化向量放在转换后的数据包中的密文之前。
它应该是经过身份验证（但未加密）数据的一部分吗？ （我假设你没有加密它......）
我看不到 RFC 在哪里指定了这一点。它应该是显而易见的吗？如果是的话，为什么？
I'm trying to implement IPSEC in the form of ESP in transport mode with using aes in galois/counter mode, according to RFC4106.
I'm supposed to put the initialization vector just before the ciphertext in the transformed packet.
Should it be part of the authenticated (but non-encrypted) data? (I'm assuming that you don't encrypt it...)
I can't see where the RFC specifies this. Should it be obvious and if so why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
据我理解 GCM 定义，不需要在中包含初始化向量相关数据 - 使用不同的初始化向量将给出不同的加密结果以及不同的完整性检查值。
这就是使用组合认证加密模式的优点，您不必关心在 MAC 中包含初始化向量。
因此，要使用 GCM 对 ESP 数据包进行编码，请执行以下操作：
As far as I understand the GCM definition, there is no need to include the initialization vector in the associated data - using different initialization vectors will give both different encryption results as well as different integrity check value anyway.
This is the advantage of using a combined authenticated-encryption mode, you don't have to care about including initialization vectors in the MAC.
So, to encode a packet for ESP with GCM, you do this:
对于 AES-GCM-ESP，IV（尤其是 8 字节的 iv）不是 AAD 的一部分。 AAD 只是 ESP 标头。
请注意，传递给 AES_GCM 的 IV 是 salt(fourbytes) + iv(esp iv of 8bytes) 的串联。一些硬件加密引擎将 IV 视为 16 字节，在这种情况下，您需要将最后四个字节填充为 0x0。
检查这个文档，它非常简洁
http://csrc.nist .gov/groups/ST/toolkit/BCM/documents/proposemodes/gcm/gcm-revised-spec.pdf
For AES-GCM-ESP, IV (esp iv of 8bytes) is not part of AAD. AAD is just the ESP header.
Note that IV which is passed to AES_GCM is the concatenation of salt(fourbytes) + iv(esp iv of 8bytes). Some hw crypto engines take IV as 16bytes in which case you need to pad the last four bytes to be 0x0.
Check this doc , it is pretty neat
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-revised-spec.pdf
不，你不应该。
应该是显而易见的吗？
通常是的。许多其他 ESP 机制的 RFC 都包含测试向量来消除此类问题。
RFC4106 没有。在讨论期间注意到了这一点，但他们没有将其写入文本： https://www.ietf.org/mail-archive/text/ipsec/2005-08.mail
不过，有一个包含测试向量的草稿文档：https://datatracker.ietf.org/doc/html/draft- mcgrew-gcm-test-01 。您会注意到 IV（“nonce”的字节 4-11，第一个示例中的
4956ed...）包含在数据包数据中明文。它们不包含在“明文”中，也不包含在“aad”中，“aad”是通过 GCM 密码验证的数据总量。还要考虑 GCM 密码本身的 IV 是盐和 ESP IV 的串联 - 称为“随机数”以避免歧义。盐是从 IKE 期间协商的密钥材料中获得的，因此它在两个端点之间达成一致，并且在 SA 生命周期内保持不变。
No, you shouldn't.
Should it be obvious?
Normally yes. Many of the other RFCs for ESP mechanisms include test vectors to dispel this kind of questions.
RFC4106 doesn't. This was noticed during discussion but they did not make it to the text: https://www.ietf.org/mail-archive/text/ipsec/2005-08.mail
There is a draft document with test vectors, though: https://datatracker.ietf.org/doc/html/draft-mcgrew-gcm-test-01 . You will notice that the IV (bytes 4-11 of the "nonce",
4956ed...in the first example) are included cleartext in the packet data. They are not included in the "plaintext" nor in the "aad", which is the total of the data authenticated by the GCM cipher.Consider also that the IV to the GCM cipher itself is a concatenation of the salt and the ESP IV - called "nonce" to avoid ambiguity. The salt is obtained from the key material negotiated during IKE, so it's agreed between both endpoints and constant for the SA lifetime.
显然这两个显而易见的答案都是正确的。
根据 RFC 4543 指定 ENCR_NULL_AUTH_AES_GMAC（无需加密的身份验证），您可以包含 IV。
然而，同一个 RFC 说，对于 AES-GCM-ESP（加密和身份验证），您没有。
有了这些信息，现在很清楚，这就是 RFC 4106 （实际上指定了 AES -GCM-ESP）也这么说，尽管我一开始并不是这么解释的。
Apparently both of the obvious answers are right.
According to RFC 4543 which specifies ENCR_NULL_AUTH_AES_GMAC (authentication without encryption), you include the IV.
However the same RFC says that for AES-GCM-ESP (encryption and authentication), you don't.
Armed with this information, it's now clear that that's what RFC 4106 (which actually specifies AES-GCM-ESP) says as well, although that wasn't how I interpreted it at first.