为什么随机 IV 对 AES-CBC 很好，但对 AES-GCM 没有答案

【问题标题】：Why is random IV fine for AES-CBC but not for AES-GCM为什么随机 IV 对 AES-CBC 很好，但对 AES-GCM 没有
【发布时间】：2016-04-21 06:08:12
【问题描述】：

我一直在使用 AES-CBC 进行加密，每次加密纯文本时都会使用随机 IV。据我所知，这是推荐的方法。

我一直在研究 AES-GCM / AES-CTR，主要用于 AEAD。我还没有用这个实现任何东西，但从我读过的所有内容来看，基本上nonce只是一个短路的IV，并且有一个用于每个加密调用的内部计数器。开发人员 / 需要确保在 32 位计数器循环返回之前更改随机数，否则相同的随机数 (IV) 可能与相同的密钥一起使用，这可能会加密相同的纯文本并泄漏加密密钥。

我不太明白为什么 AES-CBC 可以使用随机 IV，但我读过的一些内容表明 AES-GCM 的随机随机数 (IV) 是一个坏主意。我唯一能想到的是 AES-CBC 的 IV 比 AES-GCM 的 nonce 长，因此 AES-GCM 的重复 nonce 可能更大。

我需要加密从几个字节到 10 - 20 GB 的数据。我知道 AES-GCM 在计数器循环之前可以加密的数据大小（~60GB）有限制。我可以绕过这个限制，因为我的数据低于这个限制。

有人能解释一下为什么不建议为 AES-GCM 使用随机随机数吗？

【问题讨论】：

我对此有一个后续问题。使用 AES-CBC，我使用长期密钥并生成随机 IV，并将 IV 与加密数据一起保存，并将数据保存到磁盘，一切正常。在这个实现中，我不关心 AEAD。使用 AES-GCM / CTR，我仍然想使用长时间密钥。我的计划是设置加密，使用 nonce / key 加密数据并使用加密数据保存 nonce。要解密，我将设置随机数并解密数据。使用 AES-GCM / CTR 以普通形式保存 nonce 是否安全？
使用 AES-CTR / GCM，我希望对于密码的每个设置，内部计数器都设置为 0，所以如果我要加密数据以进行长期存储，不存在NONCE 与数据一起使用的感知顺序？如果我在同一个密码会话中使用相同的 NONCE 加密 PlainText1、PlainText2、PlainText3，我不需要以相同的顺序解密它们吗？
我投票结束这个问题，因为它属于 crypto.stackexchange.com

标签： encryption cryptography initialization-vector aes-gcm

【解决方案1】：

GCM 基于 CTR 模式，如果使用同一个键 (very nice example) 重复使用随机数，则会继承多次填充（或两次填充）问题。如果 IV 在 CBC 模式下被重用，那么观察者唯一能检测到的就是消息前缀的相等性。

观察者可以检测到之前发送的消息以 CBC 模式再次发送，这可能不会给他们太多，但 CTR 为他们提供了推断消息内容的能力，如果有关内容结构的一些信息是已知的。

AES-GCM 模式的随机数预计为 96 位长。如果您随机生成 nonce，那么您应该在 2^n/2=2⁴⁸ 条消息后生成一个重复的 nonce（请参阅生日问题）。也就是说，如果您使用相同的密钥生成 2⁴⁸ 条加密消息，则生成重复随机数的概率为 50%。这是相当多的消息，但它可能会更早发生。

【讨论】：

我认为 2^n/2 问题将是问题的一部分。这个例子有助于解释它。
NIST 将 2^32 条消息指定为 GCM 的硬限制，具有随机 IV，而不是 2^48。此外，如果 IV 被重复，GCM 也会泄露 GHASH 密钥，因此丢失的不仅仅是机密性 - 未来消息的真实性也是如此。

【解决方案2】：

对 GCM 使用随机 IV / nonce 已被指定为 - 例如 - NIST 的官方建议。如果有人提出不同的建议，那取决于他们。

当使用随机 IV 时，生日问题大大增加了 IV 碰撞的机会。使用随机数的默认大小（12 字节或 96 位），发生冲突的机会并不高。在该模式变得易受攻击之前，仍然可以加密超过十亿个文件或消息。

如果 GCM 变得易受攻击，那么攻击者可能会找到用于生成身份验证标签的（内部）密钥。除此之外，由于 GCM 在内部使用 CTR 模式，因此文件/消息中的数据的机密性可能会丢失。因此，如果重复静脉注射，GCM 将严重失败。

由于上述限制和漏洞，需要对随机 IV 进行仔细的协议设计和实现。因此建议使用经过良好测试的密码随机数生成器来生成 IV 的值。

有关 IV 的生成和由此产生的限制的更多信息，请参阅NIST specification SP 800-38D on GCM 的第 8.2 和 8.3 节。

在 NIST 规范中，随机 IV 需要使用完整的 96 位。因此，IV 中没有任何多余的位可以包含其他信息，因为不建议使用默认大小的 96 位以外的 IV。

NIST 指定使用相同密钥对随机生成的 IV 加密的消息限制为 2^32（四十亿）条。

如果消息的数量是一个问题，最好使用基于密钥的密钥派生算法并为每个密文派生一个新的 AES-256 位密钥。另一个可能为随机随机数提供一些安全性以防止冲突的选项是使用 AES-GCM-SIV，因为如果使用了随机数，IV 不仅仅依赖于随机数。尽管如此，即使是 SIV 模式，您也需要最大数量的消息。

【讨论】：

好吧，GCM 与额外的身份验证相反，虽然 CBC 因 IV 的可预测性而受到伤害，但对于 CTR，这件事并不是无缘无故地称为“nonce”。在这里，据我阅读，重复将完全破坏加密，特别是如果涉及已知/选择的明文，这将允许您获得加密的随机数+计数器，结果允许您使用具有相同密钥 + IV 的密码对其进行异或获取您以前不知道的其他明文。
@My1 是的，但是 GCM 预处理 12 字节 IV 实际上是一个随机数，然后将其作为计数器值提供给底层 CTR 模式。因此，您可以生成 96 位/12 字节的随机 IV/nonce，并且在 2^32 代后有大约 2^(-64) 的碰撞机会。在 CTR 模式下，情况会更加复杂，因为用户必须自己将（随机）随机数拆分为 IV - 但是 GCM 会为您执行此操作。
@MaartenBodewes 随机数仅在其长度 != 96 位时才通过 GHASH，并且 2^32 限制仅适用于长度不是 96 位的确定性随机数。使用推荐的 32 位固定字段和 64 位调用字段，限制为 2^64。

【解决方案3】：

GCM 是计数器模式 (CTR) 的一种变体。正如您所说，对于计数器模式的任何变体，基本 Nonce 不会使用相同的键重复。因此，CTR 模式 Nonce 通常包含计数器或计时器元素：保证在密钥的生命周期内不会重复。

如果 Nonce 是纯随机的，那么它重复的可能性很小。这个问题很容易避免，因此建议不要使用随机数。

在 CBC 模式下，IV 会处理第一个块的内容。如果第一个块没有改变（或使用固定的 IV），那么（仅）第一个块的加密有效地处于 ECB 模式，这是不安全的。 CBC 模式的随机 IV 可以避免这个问题。

因此处理方式的差异：CTR（以及从中派生的 GCM 等模式）需要保证唯一的 Nonce。 CBC 等模式需要随机 IV。

【讨论】：