我们在基因组学中有100 + GB的文件需要进行GCM加密，因此我们担心会遇到这种情况。问题：
这种较低限制的来源是什么？
如果您超过此限制，会发生什么（从数学上讲，不是在实现上明智的做法）？
#1 楼
限制的根源在于，GCM具有使用32位整数的固定块计数器。由于块大小为$ 2 ^ 7 $位，因此可以使用CTR组件加密的总金额为$ 2 ^ {39} $位。事实上，块计数器至少从96位随机数开始于1而不是0。众所周知，除96位以外的其他大小都会降低安全性。将其减少128位的第二个限制是因为CTR组件还用于在标签输出之前对最终的GHASH进行加密。实施上，明智的做法是，不允许您超过此限制。从理论上讲，安全性崩溃了。对于加密的数据量和生成的标签量，有不同的安全限制。对于长消息，$ n $位标签为$ 2 ^ k $阻止消息提供$ nk $位身份验证安全性，在您的情况下，文件大小在100至与96位标记一起使用时为128 GB，远低于预期的$ 2 ^ {128} $。最坏的情况是恢复哈希子键$ H $，从而允许伪造具有相同键的标签。在ECB模式下用单独的密钥加密完整尺寸的128位标签应该可以解决该问题，因为这些位将不再具有延展性。可以做为GCM实现的包装器，而只需很少的修改，开销几乎为0。需要修改实现以使用更大的块计数器，并且随机数需要更短。您将不再能够将其称为GCM，但将能够利用使GCM实现快速且耐定时攻击的所有功能和代码。一个32位的随机数和一个40位的块计数器（没有附加的GHASH）将允许每个随机数接近16TB，而如果您使用第二个密钥加密标记，则不会为每个消息更改密钥。如果您甚至考虑这样的事情，强烈建议您就修改和代码进行专业咨询，否则将需要开发新的安全证明。
其他解决方案包括使用GCM，但使用其他模式，例如Poly1305-AES。 OCB模式还建议每个密钥限制64GB，CWC模式与GCM具有相同的限制。
评论
$ \ begingroup $
@ DeepSpace101我知道您可能对自己的工作有很大的限制。如果要求您在100GB以上的文件上使用GCM而不进行分块处理，那么您将无法满足该要求
$ \ endgroup $
– Richie车架
16年1月9日在2:18
$ \ begingroup $
实际上，我认为界限比您提出的要低。如果我正确理解Iwata，Ohashi和Minematsu的论文“ Breaking and Repair GCM Security Proofs”（2012年），那么防止伪造的安全性最多为$ n-2k $（请参见定理2），并且您弄乱了现时的大小。事情似乎变得更奇怪了...
$ \ endgroup $
– SEJPM♦
16年1月9日，11：23
$ \ begingroup $
@SEJPM如果您使用非96位随机数，则GCM需要在递增之前进行GHASH迭代，这会产生计数器冲突。在删除该GHASH的情况下，攻击者的优势与96位随机数相同，约为$ 0.5（2 ^ {33}）^ 2/2 ^ {n} $ + $ 2 ^ {33} / 2 ^ {96} $ = $ 2 ^ {-63} $ + $ 2 ^ {-63} $ = $ 2 ^ {-62} $可获取最大128GB数据集和96位标记，$ 2 ^ {-63} $可包含一个128位的标记，假设每个消息具有唯一的密钥...我认为那是我从那篇论文中得到的
$ \ endgroup $
– Richie车架
16 Jan 10'在4:29
$ \ begingroup $
@RichieFrame是键的限制，还是现时/ iv？使用GCM，如果增加IV，是否可以使用同一密钥大于64GB？
$ \ endgroup $
–泰勒·比斯科（Tyler Biscoe）
20 Sep 14 '17：25
$ \ begingroup $
@TylerBiscoe问题在于IV的块计数器组件的大小，并且是随机的。如果您增加随机数，则可以将一条大消息分解成碎片并分别进行加密，那么在遇到基于模式的安全问题之前，您可以安全地加密大约40亿条64GB消息
$ \ endgroup $
– Richie车架
20 Sep 14'19:46
#2 楼
我不同意此处给出的其他答案和评论。 96位随机数的使用可提供最佳边界，但这当然不是使用GCM的唯一方法。而且，降解是逐渐的。并非没有其他不安全的情况。话虽如此，使用96位计数器加密超过$ 2 ^ {32} $个块是完全不安全的，因为相同的计数器将重复出现，这是完全的灾难。这是使用88位随机数。然后，您最多可以加密$ 2 ^ {47} $位。评论
$ \ begingroup $
要使用此更好的解决方案，您可能需要偏离标准。如果仅使用具有随机实现的88位随机数，它将将该随机数散列为96位随机数，并且仍然使用32位计数器，这不能解决问题。
$ \ endgroup $
– K.G.
16年1月10日在9:15
$ \ begingroup $
同样，随着输入数据长度以及使用同一密钥加密和解密的消息数量的减少，这种影响是逐渐的。操作员正在寻找的数据长度大大降低了安全性的界限，即使每个密钥只有一条消息也是如此
$ \ endgroup $
– Richie车架
16年1月10日在9:17
$ \ begingroup $
具有标准GCM的88位随机数仍仅允许$ 2 ^ {32} -2 $块，但将私密性从单个完整大小的消息的$ 2 ^ {65} $减少到$ 2 ^ {64} $仅256条消息。那是PRIVACY绑定，而不是身份验证绑定，这很糟糕。 96位标记接受17.7亿条消息以实现相同的减少，并且该消息计数将非96位随机数版本减少到小于$ 2 ^ {45.6} $
$ \ endgroup $
– Richie车架
16年1月12日在7:31
#3 楼
如果确实有涉及价值超过2亿美元的机器，那么您大概拥有安全的物理环境。这意味着还有另一种选择：在昂贵，不灵活的机器之外进行所有加密，并使用与外界隔离的物理安全网络以明文形式向/从机器传输数据。如果攻击者无法访问网络以篡改网络（因为它位于武装警卫的密闭房间中），则以纯文本格式通过网络传输数据不是漏洞。评论
$ \ begingroup $
我也输入了“ k”，这台机器只是200,000或200k ...错字。我现在不能编辑该旧评论，但很抱歉：)
$ \ endgroup $
– DeepSpace101
16-2-19在4:58
评论
“这种较低限制的来源是什么？”-安全证明。您降低了安全限制，降低了安全限制。但这只是我记得的内容（我现在找不到任何好的来源->没有答案）。为何无法对数据进行分块，即以小块（10GB）的块加密所有内容，是什么原因？问题出在认证标签上，而不是数据加密上，因此数据仍然是安全的。我假设您将为每个文件使用唯一密钥？
@RichieFrame在那儿等。在GCM使用CTR时，不是来自GCM IV的128-96 = 32位是包含计数器的输入块的一部分。如果实现溢出计数的32位空间，则我希望是1.下一个IV的密码流将匹配此64GB +密码流或2。64GB +和0到64GB密码流将匹配。不管哪种方式，都会显示明文的XOR（除非没有暗示的“下一个IV”）。很难在数学上讲而不是在实现上讲明智，因为这里故意没有定义数学。
@ ThomasM.DuBuisson是的，即使您使用64位IV，我也忘记了固定的32位块计数器。溢出不会增加IV，而是会引发错误。考虑到这一事实，Poly1305对于大型数据集似乎是更好的选择。
请改用ChaCha20-Poly1305。 libsodium可以在使用64位内部计数器的模式下执行此操作，因此对于更大的消息是安全的（我不确定实际的限制）。如果必须使用AES，请使用其他身份验证机制，例如HMAC-SHA2，Blake2，Poly1305-AES或SHA3。