根据RFC4106，我正在尝试在传输模式下使用aes在galalois/counter模式下以ESP形式实现IPSEC。
我应该把初始化向量放在转换后的数据包中的密文前面。
它应该是已验证(但未加密)数据的一部分吗?(我假设你不加密…)
我看不出RFC在哪里指定了这个。它应该是显而易见的吗?如果是，为什么?
就我所理解的GCM定义而言，没有必要在相关数据中包含初始化向量-使用不同的初始化向量将给出不同的加密结果以及不同的完整性检查值。
这是使用组合身份验证加密模式的优点，您不必关心MAC中是否包含初始化向量。
因此，要用GCM为ESP编码数据包，您可以这样做:
- 获取密钥 生成IV
- 计算相关数据(来自SPI和序列号)
- 获取明文
- 将IV、关联数据、密钥、明文传递给GCM算法
- 从GCM算法中获取密文和ICV
- 发送IV、密文和ICV
对于AES-GCM-ESP, IV (esp IV为8字节)不是AAD的一部分。AAD只是ESP头。注意，传递给AES_GCM的IV是salt(4字节)+ IV(特别是8字节的IV)的串接。一些hw加密引擎将IV作为16字节，在这种情况下，您需要将最后四个字节填充为0x0。
检查这个文档，它非常整洁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...)包含在数据包数据中明文。它们不包含在"明文"中。
还要考虑到GCM密码本身的IV是salt和ESP IV的连接-称为"nonce"避免歧义。盐是从IKE协商的关键材料中获得的，所以它在两端之间是一致的，并且是SA生存期的常数。
显然这两个显而易见的答案都是正确的。
根据RFC 4543指定的ENCR_NULL_AUTH_AES_GMAC(不加密的身份验证)，你包括IV.
然而，相同的RFC说，对于AES-GCM-ESP(加密和身份验证)，你不需要。
有了这些信息，现在很清楚RFC 4106(它实际上指定了AES-GCM-ESP)也是这么说的，尽管我一开始不是这么解释的。