使用 AES-GCM 协议的 nonce / IV 的来源和重要性答案

【问题标题】：Source and importance of nonce / IV for protocol using AES-GCM使用 AES-GCM 协议的 nonce / IV 的来源和重要性
【发布时间】：2011-04-17 01:29:10
【问题描述】：

我正在制作一个使用 AES 加密的数据包（即不是流）的协议。我决定使用 GCM（基于 CTR），因为它提供集成身份验证并且是 NSA 套件 B 的一部分。AES 密钥是使用 ECDH 协商的，其中公钥由受信任的联系人签名，作为网络的一部分-使用 ECDSA 之类的信任。 ~~我相信我需要一个用于 GCM 的 128 位随机数/初始化向量，因为即使我为 AES 使用 256 位密钥，它始终是一个 128 位块密码（对吗？）~~读取 BC 代码后使用 96 位 IV。

我绝对没有实现我自己的算法（只是协议——我的加密提供者是 BouncyCastle），但我仍然需要知道如何使用这个随机数而不是自找麻烦。使用相同 DH 密钥的两个人之间使用的 AES 密钥将保持不变，因此我知道不应将相同的 nonce 用于多个数据包。

我可以简单地在数据包中添加一个 96 位的伪随机数并让接收者将其用作随机数吗？这是点对点软件，可以随时发送数据包（例如，即时消息、文件传输请求等），速度是一个大问题，因此最好不必使用安全的随机数来源。随机数根本不必保密，对吧？还是必须像“加密安全”的 PNRG 一样随机？维基百科说它应该是随机的，否则它很容易受到选择的明文攻击——但在这两种说法旁边都有一个“需要引用”，我不确定这是否适用于分组密码。我真的可以使用一个计数器来计算从 1 开始的给定 AES 密钥发送的数据包数量（与 128 位块数量的计数器分开）吗？显然，这将使随机数可预测。考虑到 GCM 会进行身份验证和加密，这会损害其身份验证功能吗？

【问题讨论】：

请注意 - security.stackexchange.com/questions 可能更适合回答此类问题。
@Eugene Mayevski 'EldoS Corp 他刚刚从更大的社区中得到了更好的答案。
@Eugene Mayevski 'EldoS Corp 看，没什么好担心的。所以回答了他的问题。
@Rook 你是对的，但重点完全不同。 security.stackexchange.com 是针对与安全相关的问题而创建的，您肯定知道 StackOverflow 和姊妹站点的创建是为了组织类似于 wiki 的问题和答案知识库。并且将有关某个主题的所有问题集中在一个地方要比将它们分散在多个站点上要好得多。因此，虽然 OP 的短期目标是获得最广泛的曝光，但社区的兴趣可能是将编程安全问题和理论安全问题分开。
@ugene Mayevski 'EldoS Corp 那么你是建议人们继续在两个网站之间交叉发帖吗？ Secuirty.se 会很有用，但目前有近十几个用户定期回答问题，这不是很有趣。

标签： security cryptography aes block-cipher

【解决方案1】：

GCM 是带有身份验证的分组密码counter mode。计数器模式有效地将块密码转换为流密码，因此流密码的许多规则仍然适用。需要注意的是，相同的 Key+IV 将始终产生相同的 PRNG 流，并且重复使用此 PRNG 流可能导致攻击者通过简单的 XOR 获得明文。在一个协议中，相同的 Key+IV 可以用于会话的生命周期，只要模式的计数器不换行（int 溢出）。例如，一个协议可以有两方并且他们有一个预先共享的密钥，然后他们可以协商一个新的加密 Nonce，用作每个会话的 IV（记住 nonce 意味着使用 ONLY ONCE )。

如果您想使用 AES 作为分组密码，您应该查看 CMAC Mode 或者可能是 OMAC1 变体。在 CMAC 模式下，仍然适用 CBC 的所有规则。在这种情况下，您必须确保每个数据包都使用一个唯一的 IV，即also random。然而，重要的是要注意重用 IV 并没有像重用 PRNG 流那样可怕的后果。

【讨论】：

感谢您的回答 - 所以我将为每个数据包使用不同的随机随机数。可以简单地将随机数添加到密文中吗？
@bowenl2 不，您为每个 SESSION 使用一个 key+nonce，内部计数器递增以说明您加密了多少字节，这样您就不会重复使用 PRNG .这就像每个数据包都有一个 IV。下次建立连接时，您不能使用相同的 Nonce+Key。但是，如果您丢失一个数据包，您将面临失去同步的危险。
再次感谢 - 这是一个错字。我现在为每个会话使用 96 位随机数，由发起连接的一方发送。
CTR 不会只产生流密码 - 它是随机可搜索的，这不是流密码的属性。
@Nick Johnson 对于需要考虑数据包丢失的协议来说非常重要。但是我关于重用 prng 的观点仍然有效。

【解决方案2】：

我建议不要制定自己的安全协议。您需要考虑几件事，即使是合格的密码学家也可能会弄错。我建议你参考 TLS 协议 (RFC5246) 和数据报 TLS 协议 (RFC 4347)。选择一个库并使用它们。

关于您在 GCM 模式下使用 IV 的问题。我会告诉你 DTLS 和 TLS 是如何做到的。它们使用显式随机数，即包含在每个数据包中的消息序列号（64 位），以及不传输的秘密部分（高 32 位），并且源自初始密钥交换（请参阅 RFC 5288更多信息）。

【讨论】：

我现在肯定倾向于直接在 TCP 上使用 TLS，以尽量减少我（不可避免地）搞砸的影响，但我仍然对它背后的理论感兴趣。另外我相信第二段中的内容只是为了防止 CBC 攻击，但我可能是错的。
关于您的建议，请在此处查看我的问题：stackoverflow.com/questions/5721607/…