我正在制作一个使用AES加密的数据包（即非流）的协议。我决定使用GCM（基于CTR），因为它提供了集成身份验证，并且是NSA套件B的一部分。使用ECDH协商AES密钥，其中公钥由可信联系人签名，作为网络的一部分 - 使用像ECDSA这样的信任。 我认为我需要一个用于GCM的128位随机数/初始化向量，因为即使我使用256位密钥进行AES，它总是一个128位分组密码（对吗？）我会在读取BC代码后使用96位IV。
我绝对没有实现我自己的算法（只是协议 - 我的加密提供程序是BouncyCastle），但我仍然需要知道如何使用这个nonce而不用自己的脚。在具有相同DH密钥的两个人之间使用的AES密钥将保持不变，因此我知道不应将同一个随机数用于多个数据包。
我可以简单地在数据包前加一个96位伪随机数，并让收件人将其用作nonce吗？这是点对点软件，数据包可以随时发送（例如，即时消息，文件传输请求等），速度是一个大问题，所以最好不要使用安全随机数源。 nonce根本不必是秘密的，对吧？或者必然像“加密安全”PNRG一样随机？维基百科说它应该是随机的，否则它很容易受到选择的明文攻击 - 但是两个声明旁边都有一个“需要引用”，我不确定这是否适用于分组密码。我是否可以使用一个计数器来计算从给定的AES密钥开始的1个发送的数据包数（与128位数的计数器分开）？显然这会使nonce可预测。考虑到GCM进行身份验证以及加密，会不会影响其身份验证功能？
答案 0 :(得分：6)
GCM是带有身份验证的分组密码counter mode。计数器模式有效地将分组密码转换为流密码，因此流密码的许多规则仍然适用。重要的是要注意，相同的Key + IV将始终产生相同的PRNG流，并且重用该PRNG流可能导致攻击者通过简单的XOR获得明文。在协议中，只要模式的计数器不包装（int溢出），就可以在会话的生命周期中使用相同的Key + IV。例如，协议可以有两方并且它们具有预共享密钥，然后它们可以协商用作每个会话的IV的新加密Nonce（记住nonce意味着使用 ONLY ONCE ）。
如果您想使用AES作为分组密码，您应该查看CMAC Mode或OMAC1变体。使用CMAC模式，仍适用于CBC的所有规则。在这种情况下，您必须确保每个数据包使用唯一的also random IV。然而，重要的是要注意重用IV不会像重用PRNG流那样产生可怕的后果。
答案 1 :(得分：1)
我建议不要制作自己的安全协议。您需要考虑几件事情，即使是合格的密码学家也可能会弄错。我会把你推荐给TLS 协议（RFC5246）和数据报TLS协议（RFC 4347）。选择一个库并使用它们。
关于您在GCM模式下使用IV的问题。我会告诉你DTLS和TLS是如何做到的。它们使用显式的随机数，即包含在每个数据包中的消息序列号（64位），其中一个未传输的秘密部分（高32位），并且是从初始密钥交换中派生的（检查RFC 5288为更多信息）。