根据RFC 4106的AES-GCM中IV的大小

Question

RFC 4106指定了大约现在。它含有4倍大小的盐和8倍大小的iv型盐。此外，RFC指定在通过Internet密钥交换(IKE)建立的安全关联开始时分配salt，而salt值是恒定的。但是，所有关于AES-GCM的所有实现和描述都将iv指定为12个八位数，没有考虑盐值。

AES-GCM将输入作为密钥、IV、明文和附加身份验证数据(AAD)。AES-GMAC是AES-GCM的一个变种，它通过将明文保持为零比特来提供数据认证.

其他关于AES-GCM模式的问题是。

1. 我知道AES-GCM可以用于数据的认证，我们可以只使用AES-GCM模式进行加密，而忽略身份验证吗？
2. 使用AES-GCM加密时必须使用iv吗？
3. AES-GMAC的允许变体是什么，如AES-GMAC 128、AES-GMAC 256等？

Answer 1

1. 我知道AES-GCM可以用于数据的认证，我们可以只使用AES-GCM模式进行加密，而忽略身份验证吗？

让我们记住，AES-GCM是使用关联数据(AEAD)进行身份验证的加密，它使用

• AES在CTR模式下保密，只能提供CPA的安全性
• GMAC用于完整性和认证，这是一个基于名为GHASH的多项式哈希函数的韦格曼-卡特。

这种组合是一种加密-然后-MAC时尚。

当然--不建议--人们可以使用AES-GCM而不进行身份验证，只需丢弃身份验证标记即可。由于GCM使用前两个计数器，如果您使用从2开始计数器，这将等于CTR。

在生成和需要标记的标准实现中，会出现一些问题，主要是性能问题。一个人可能需要生成它，发送它，提供给解密者，并忽略任何标签错误！等等！或者可能需要修改源代码。

由于不使用GCM部件，人们只能在大多数CPA安全性中获得机密性，而可以使用CTR模式进行保密。一个不需要GCM部分。只需使用普通CTR模式，这将减少GCM计算的处理时间。这在现代密码学中是不可取的。至少

• IND-CCA2 2-密文在自适应选择密文攻击下的不可分辨性

是必需的。

1. 使用AES-GCM加密时必须使用iv吗？

(IV，key)对的使用不得超过一次。如果使用相同的密钥重复使用IV，就会像在两个时间盘中一样引起婴儿床拖动攻击，而且还可以有一个签名伪造的灾难性故障。。

如果你能保证你总是使用一个新的钥匙，那么你可以保持IV固定甚至为零。这也是不可取的，因为你降低了碰撞概率的IV-密钥对，而不是建议的作者，也。如果IV和加密密钥是随机生成的，那么在生成2^{64}密钥而不是2^{128}之后，您将与0的概率发生冲突。如果我们坚持使用RFC 4106，那么2^{112}，因为它使用92位IV (RFC 4106使用nonce而不是IV来避免与ESP的IV混合)。

1. AES-GMAC的允许变体是什么，如AES-GMAC 128、AES-GMAC 256等？

RFC 4106只提到AES-GCM.如果你想使用它，你只有GCM。

GMAC (Galois Message Authentication Code)是GCM的一个纯身份验证变体，它可以形成增量式消息认证码。在NIST 800-38d中，GCM和GMAC是标准化的。

在只有5个密码套件的TLS 1.3中也使用AES-GCM .

但是，所有关于AES-GCM的所有实现和描述都将iv指定为12个八位数，没有考虑盐值。

NIST规范(NIST.SP.800.P.800.P.800.P.800-38D)推荐12位字节，如果您使用16位字节或更一般的话，如果您提供一个不等于12字节的位元，那么它将用GHASH进行处理，之后的大小将是12字节。

if len(IV) = 96 then 
    J_0 = IV || 0^{31}1
else 
    J_0=GHASH_H(IV||0^{s+64}||len(IV_64))

在RFC 4106中定义的盐。NIST是政府的，如果你在美国，你需要使用NIST标准来兼容和竞争。

盐场是在安全关联开始时分配的四个八进制值，然后在安全关联的生命周期中保持不变。

所以它是特定于协议的。

Answer 2

凯拉拉卡回答了你的问题，但我相信有些事情需要澄清：

RFC 4106指定了大约现在。它含有4倍大小的盐和8倍大小的iv型盐。此外，RFC指定在通过Internet密钥交换(IKE)建立的安全关联开始时分配salt，而salt值是恒定的。但是，所有关于AES-GCM的所有实现和描述都将iv指定为12个八位数，没有考虑盐值。

首先，澄清术语(至少，我将在下面的回答中使用的术语)：

• 这是传递给GCM例程的(通常为96位)值。
• IV -这是包内的值-使用GCM的IPsec使用64位IVs。
• 盐-这是额外的价值，包括在食谱中，以产生现在。

RFC 4106专门介绍如何在IPsec中使用GCM；因此，它有一个生成GCM所需的当前(您称之为'iv')的方法。它通过讨论由加密器选择的8个字节(他将其放置在数据包中的'iv字段‘中，解密器从数据包中提取的字节)，以及用于密钥派生( 'salt')的4个字节并将它们连接起来。

这是特定于IPsec的(实际上，TLS对GCM的使用做了同样的事情)；其他使用GCM的协议可能以不同的方式生成(和通信)它们的非use。因为密码例程通常与协议无关，所以它们不会内置特定于IPsec的配方。相反，他们会假设某个特定于协议的东西会生成现在，并将整个时间传递进来。

至于为什么IPsec使用这个特定的方法来生成GCM，这是为了挫败潜在的多目标攻击。假设攻击者有大量GCM加密会话，并且他希望恢复其中一个会话的内容(而不是真正关心是哪个会话)。此外，假设GCM实现对每个会话使用相同的IVs (例如，第一个加密数据包可能总是使用IV为0)。然后，攻击者可能要做的是猜测AES密钥，并生成GCM隐私密钥流，并查看是否对任何会话的初始数据包都是正确的密钥流(在看似合理的假设下，这是有效的)。如果他能做到这一点，那就意味着，对于128个位密钥和N会话，他预期的破坏其中一个会话的工作是2^{128}/N试解密，这比我们想要的要少。但是，通过包含32位salt (不同会话之间的不同)，这种预期的工作工作量将增加到2^{160}/N (因为他必须猜测salt以及密钥)；特别是，这意味着这种多目标攻击实际上比简单的蛮力攻击效率要低，除非N > 2^{32}，这是相当多的。请注意，此salt实际上无助于对抗针对单个会话的暴力攻击；它也不会造成伤害。而且，它并不一定是秘密的(然而，我们也没有什么特别的理由去发表它.)