假设较短的IV不好。假设仍满足IV生成的所有其他限制，使用更长的IV会对安全带来负面影响，还是对性能造成严重影响而又不增加任何安全利益？在GCM模式下使用AES进行大小和IV传输时会特别指出
对于GCM，强烈建议使用12字节的IV，因为其他IV长度将需要额外的计算。 br />我对此声明非常感兴趣，但是我无法找到有关使用更长的IV时的这些“附加操作”或其他安全隐患的解释。 NIST关于块密码模式的建议：伽罗瓦/计数器模式（GCM）和GMAC并没有为我澄清这一点。遵循惯例？
#1 楼
根据GCM的建议（如果语句重写）：如果$ \ operatorname {len}（IV）= 96 $，则$ Y_0 = IV || 0 ^ {31} 1 $ else
$ Y_0 = \ operatorname {GHASH}（H，\ {\}，IV）$。 IV以外的96位。这就是为什么原始提案提出此建议的原因：
可以更有效地处理96位IV值，因此对于效率至关重要的情况，建议[ed：this]长度。
但在安全性部分中，也解释了GHASH先前未考虑GCM的IV处理：
1979年，Diffie和Hellman [21]提出了反模式，Bellare等人在强烈的具体意义上证明了反模式是安全的。等[22]。虽然GCM的安全性证明取决于这些证明，但还是存在一些差异。从块密码密钥$ K $派生散列密钥$ H $，对$ IV $进行散列以及在IV处理和消息身份验证中使用该密钥都是重要的细节。
NIST SP-800 38D有整章-第8章-专门讨论密钥和IV的唯一性以及GCM的最大调用次数。
然后，这同样适用于其他任何密码，特别是那些基于CTR模式加密的密码（包括GCM和EAX） ，CCM等）。
我的建议是，如果您有小的但独特的IV输入，则可以根据NIST中的提示将输入扩展为12个字节SP-800-38D：8.2.1确定性构造。
如果不可能生成唯一且小于等于12个字节的值，则可能需要考虑由12个组成的完全随机IV b是的。
评论
$ \ begingroup $
Maarten，如果您添加结果并链接到其他答案，此答案会更好
$ \ endgroup $
– kelalaka
19年1月5日，9：57
$ \ begingroup $
我想您只是这样做的：）但是，这个问题尤其适用于IV为96位（与96没有区别）的情况，因此，如果您不介意，我将不回答。除非您是别的意思，否则我很乐意得到纠正。
$ \ endgroup $
–马腾·博德威斯♦
19年1月5日，11：50
$ \ begingroup $
是:)如果没有加什的深入了解，if语句的结果对我来说并不明确。
$ \ endgroup $
– kelalaka
19年1月5日在12:03
#2 楼
在一般情况下，安全性目标是降低在使用给定密钥实例化GCM密码时内部128位计数器块获得相同值的可能性。结合CTR模式，这是灾难性的。使这种可能性最小的最佳策略取决于IV的生成方式。
情况1：IV是确定性的96位long
如果IV是确定性的，则意味着发送方可以访问可靠的机制（如计数器），以通过使用同一密钥完成的所有调用来生成唯一值序列。 >
96位IV被直接复制到计数器块中，因此计数器的唯一性直接转移到计数器块中。
IV（和计数器块）仅在$ 2 ^之后重复。 96} $调用，这是一个巨大的数目。
NIST规范要求您实际上可以将32位的IV固定为上下文信息，而只有64位的计数器。
案例2：IV是确定性的，但长于96位
如果IV是确定性的，但长于96位，则计数器的唯一性不会转移到counter blo ck。
现在，您必须考虑生日悖论的后果，因为最初的计数器现在将成为IV的摘要。具体来说，您在计数器块中最终得到96个随机位，它们可能会发生冲突。
在$ 2 ^ {48} $调用后，您很有可能以50％的概率发生冲突。
如果为了将概率降低到$ 2 ^ {-32} $以下（根据NIST的要求），您必须在$ 2 ^ {32} $调用之前更早停止。
情况3：IV是随机的
如果每次调用均随机创建IV，则生日悖论也会以96位随机数出现。
您将需要使用不超过$ 2 ^ {32的相同密钥来调用密码。 }在所有情况下均为$次。
结论
建议使用96位随机数是出于互操作性的考虑（例如，每个人仅使用一个长度就更容易）和效率。计数器（并且-非正式地-仅当您在同一密钥下创建许多密文时）。如果随机产生随机数（这是迄今为止最常见的方法），则较长的随机数也不会降低安全性。比起96位随机随机数更安全，至少在短明文情况下（例如，占用$ << 2 ^ {32} $块）。
原因是在前一种情况下，32位CTR计数器字段也是随机的，而该字段固定为$ 0 ^ {31} ||后者为1 $（请参阅NIST SP 800-38D中的7.1节）。
如果随机随机数较长，则可能会在初始计数器块中发生冲突，目标概率为$ 2 ^ {-32}仅在$ 2 ^ {48} $调用后才使用$，
这比使用96位长的随机随机数得到的绑定更好。
评论
GCM在内部运行CTR，这需要一个16字节的计数器。 IV提供了其中的12个，其他4个是实际的逐块计数器。如果您提供大于12字节的IV，则需要对其进行“散列”处理，以免发生冲突，并不必要地提高IV破坏性（毁灭性）重用的风险。较短的IV可能会发生类似情况（如果要对其进行后期处理，我不确定），或者您遇到类似的问题，因为从中选择唯一IV的空间较小。如果我没记错的话，GCM只是执行这些计算以从给定的字节重新生成12字节的IV。因此，这些计算只会损害安全性，永远不会更好。
当IV为96位长时，内部CTR密码的4字节计数器始终为1。当IV的长度不同时，CTR的4字节计数器取自IV的GHASH-因此它被均匀地随机分配跨越32位。这意味着-当IV是从RNG提取时，这是每个人都做的-由于生日的矛盾，提供非标准的128位IV似乎比标准的96位IV更安全（尽管速度较慢）。