我一直在使用 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 使用随机随机数吗？
GCM 基于 CTR 模式，如果使用相同的键重用随机数（非常好的示例），则会继承多次填充（或两次填充）问题。如果 IV 在 CBC 模式下重用，那么观察者唯一能检测到的就是消息前缀的相等性。
观察者可以检测到先前发送的消息以 CBC 模式再次发送，这可能不会给他们太多，但如果有关内容结构的一些信息已知，CTR 为他们提供了推断消息内容的能力。
AES-GCM 模式的随机数预计为 96 位长。如果您随机生成随机数，那么您应该在 2 n/2 =2 48 条消息后生成一个重复的随机数（请参阅生日问题）。也就是说，如果您使用相同的密钥生成 2 48 条加密消息，则生成重复随机数的概率为 50%。这是相当多的消息，但它可以更早地发生。
对 GCM 使用随机 IV / nonce 已被指定为 - 例如 - NIST 的官方推荐。如果有人提出不同的建议，那取决于他们。
当使用随机 IV 时，生日问题大大增加了 IV 碰撞的机会。使用随机数的默认大小（12 字节或 96 位），发生冲突的机会并不高。在该模式变得易受攻击之前，仍然可以加密超过十亿个文件或消息。
如果 GCM 变得易受攻击，那么攻击者可能会找到用于生成身份验证标签的（内部）密钥。除此之外，由于 GCM 在内部使用 CTR 模式，因此文件/消息中的数据的机密性可能会丢失。因此，如果重复一次 IV，GCM 将失败。
由于上述限制和漏洞，需要对随机 IV 进行仔细的协议设计和实现。因此，建议使用经过良好测试的密码随机数生成器来生成 IV 的值。
有关 IV 生成和由此产生的限制的更多信息，请参阅 GCM 上的 NIST 规范 SP 800-38D的第 8.2 和 8.3 节。
在 NIST 规范中，随机 IV 需要使用完整的 96 位。因此，IV 中没有任何备用位可以包含其他信息，因为不建议使用默认大小的 96 位以外的 IV。
NIST 指定使用相同密钥对随机生成的 IV 加密的消息限制为 2^32（四十亿）条。
如果消息的数量是一个问题，最好使用基于密钥的密钥派生算法并为每个密文派生一个新的 AES-256 位密钥。另一个可能为随机随机数提供一些安全性以防止冲突的选项是使用 AES-GCM-SIV，因为如果使用了随机数，IV 不仅仅依赖于随机数。尽管如此，即使对于 SIV 模式，您也需要最大数量的消息。
GCM 是计数器模式 (CTR) 的一种变体。正如您所说，对于计数器模式的任何变体，重要的是不要使用相同的键重复 Nonce。因此 CTR 模式 Nonce 通常包括一个计数器或一个计时器元素：保证在密钥的生命周期内不会重复的东西。
如果 Nonce 是纯随机的，那么它重复的可能性很小。这个问题很容易避免，因此建议不要使用随机数。
在 CBC 模式下，IV 会处理第一个块的内容。如果第一个块没有改变（或使用固定的 IV），那么（仅）第一个块的加密有效地处于 ECB 模式，这是不安全的。CBC 模式的随机 IV 避免了这个问题。
因此处理方式的差异：CTR（以及从中派生的 GCM 等模式）需要保证唯一的 Nonce。CBC 等模式需要随机 IV。