GCM模式加密的实际缺点

#1 楼

与CBC模式和HMAC相比，GCM模式通常是更好的选择。但是，我将详细介绍它不一定是的地方。就像Richie Frame一样，我也不同意CBC + HMAC始终是最好的比较目标。我添加了其他一些细节。希望您觉得它们有用。

针对CBC和HMAC

我将首先讨论不利之处。

GCM（GHASH）的身份验证部分是GHASH比HMAC弱，它提供了最大的128位身份验证标签，而HMAC允许更长的标签（HMAC-SHA-256将允许256位身份验证标签）。此外，在某些情况下，伪造GHASH标签比HMAC更容易：


与任何基于标签的身份验证机制一样，如果对手随机选择$ t $位标签对于给定的概率为$ 1/2 ^ t $的数据，它应该是正确的。但是，使用GCM，对手可以选择与密文和AAD的总长度成比例的，增加此概率的标签。 （来自NIST SP 800-38D。）


使用GCM模式的实施通常使用短IV（96位），实际上，例如NIST SP 800-38D建议使用96位IV。 （定义了更长的IV，但是它们需要额外调用GHASH函数。）
96位IV（GCM）可能太短了，而128位IV（CBC）就足够了。考虑例如随机IV的碰撞概率。

GCM的优点：正确实施的GCM几乎总是更快，并且比正确操作AES + HMAC组合更容易使用GCM。 CBC模式需要对块大小进行填充输入，因此，如果输入不是块大小的倍数，则GCM模式将产生较小的输出。

针对CTR + HMAC

因为AES也可以通过CTR模式获得并行化好处，CTR + HMAC与GCM非常相似，并且可以很好地执行。如果身份验证标签要求超出了GCM所能提供的范围，它可能会更好。

反对CCM

CCM模式在很大程度上类似于GCM模式。最大的好处是实现所需的代码（SW）或门（HW）更少，但CCM实现通常比GCM慢。硬件实现门数。

SIV-AES和AES-KW

可以使用AES-GCM（密钥包装）包装其他密钥。

对于目标为密钥包装（使用另一个密钥对密钥进行加密）的经过身份验证的加密，SIV-AES和AES-KW算法通常比AES-GCM更好。从某种意义上说，更好的是它们可以在不依赖于随机数生成（或确定性IV生成器）的情况下使用，并且它们的输出可以更小，因为除了加密的输出和身份验证标签之外，不需要IV。 （这些通常被认为是确定性身份验证加密的好处。）

密钥，IV对重用

我已经提到过IV，密钥对重用。

GCM模式不能抵抗Key IV组合的重用。为了避免这种情况，某些国家（如NIST）对GCM模式的正确使用提出了比其他模式更多的要求。从安全性的角度来看，这是一个好主意，但它可能会减少该模式的允许使用。

通常，对于同意或运输新密钥作为一部分的使用，GCM最方便。协议（TLS或IPsec）。如果在需要持久存储密钥的情况下使用，则确保IV唯一性可能很麻烦。

NIST意识到了这一陷阱。 NIST的CMVP（加密模块验证程序，也称为FIPS 140-2验证程序）具有谨慎使用GCM（FIPS 140-2 IG A.5）的要求。经FIPS批准的GCM模式实现在使用密钥时需要非常小心，因为在GCM模式下，密钥的重用不允许发生IV对。

CBC-ESSIV

AES-CBC模式可用于磁盘加密（尤其是ESSIV，请参见Wikipedia磁盘加密理论）。 GCM通常使用较小的IV长度且不具有IV抗碰撞的事实，使得很难将其应用于需要对大量块进行加密且加密未按顺序进行的情况（确定性的IV增加就可以了） 。因此，AES-GCM并不是用于加密存储的数据，而是用于传输中的数据。

摘要

GCM是一种非常好的操作模式，而且它通常比CBC + HMAC等传统算法组合更方便。但是，它不是通用解决方案（没有任何一种模式），而是仅对传输中的大量数据最方便。

#2 楼

在某些情况下，开发人员使用在英特尔处理器中找到的新PCLMULQDQ指令实现了新版本的GHASH算法，并且实现中的错误允许伪造消息。代码更改似乎可以提高AES-GCM在较新处理器以及具有不支持PCLMULQDQ的其他内核的处理器上的性能。该错误并非特定于新指令，而是新的聚合模式，该模式允许对8个块进行并行加密，以减少多核处理器上硬件AES指令的延迟。

该错误的详细信息和AES-GCM认证算法的脆弱性

中描述了如何利用它。代码是针对OpenSSL的，发生在以下情况下：

$（ {len / 16}）$ $ mod $ $ 4 = 1 $

$ len> 64 $

其中$ len $是GHASHED缓冲区的大小（以字节为单位）。 br />满足此条件的$ len $的值是80、144，以及任何其他值，它们从80递增64的倍数。他们使用的NIST测试值仅包括64字节消息和最多20字节的附加数据。没有密文的最终测试验证了128字节的附加数据。这些都不符合该bug显现的标准。该错误几乎使它进入了OpenSSL 1.0.2，但在一个月内被捕获并立即修复。

该错误继续将$ N + 1 $数据块发送到GHASH而不是$ N $。附加块$ J $的数据就是该内存位置中发生的任何事情。

OpenSSL应该执行以下计算，以从当前标签$ T $生成新标签$ T2 $。以及由$ N $个块组成的附加消息$ M $（例如5个块或80个字节）：

$ T2 =（（T + M_1）* H ^ N）+（M_2 * H ^ {N-1}）$ $ ... $ $ + $ $（M_N * H ^ 1）$

实际执行的操作是：

$ T2'= （（T + M_1）* H ^ {N + 1}）+（M_2 * H ^ {N-1}）$ $ ... $ $ + $ $（M_N * H ^ 2）+（J * H ^ 1）$

除了无效的身份验证标签外，它还从不应有的内存位置中提取了16个字节的数据。如果$ J $包含空字节，则无效的身份验证标签等于$ T2 * H ^ 1 $

可以利用此漏洞的攻击类型包括：


使用错误的实现将消息发送到接收者
使用正确的实现将消息伪造，但是
身份验证标签对接收者有效。
消息是如果将正确的实现方式发送给具有错误实现方式的接收者，则会伪造该消息，但
身份验证标签对接收者而言是有效的。

在第一种情况下，攻击者必须知道数据块J的值，并且附加身份验证数据的第一个块必须为零。在第二种情况下，攻击者必须能够修改传入的内存缓冲区。

由于密文的长度和经过身份验证的数据是GHASH函数的第一个输入，因此它们的大小不可修改作为攻击的一部分。此外，这更多是应用程序错误，而不是算法本身存在问题，但是，此处看到的错误类型来自尝试利用GCM优于CBC + HMAC的性能优势。 CTR + HMAC也是一种非常有效的模式，可以在没有多项式MAC复杂性的情况下更好地利用多核处理。

针对这种类型的bug实施攻击的难度也很高，因为这需要攻击者有权访问系统内存。拥有资金雄厚的情报机构的国家很可能会利用这一点。由于OpenSSL的盛行，因此如果将它迅速普及，它将很快被捕获，并且从长远来看不会产生太大影响。这种类型的攻击对于以与GCM相同的方式运行的任何多项式MAC有效。

除此之外，GCM赖以建立安全性的原始证据在2012年被发现是无效的，但新证据使GCM得以维持其预期的安全性。 （例如32位）身份验证标签，并且有足够的数据将安全级别降低到可攻击的水平。

最好的示例是具有8位标签的VOIP应用程序。伪造消息平均需要进行128次尝试，因此可以恢复$ H $的7位。少于1000次伪造尝试将完全揭示$ H $，从而允许伪造所有数据包。使用8位标签，此攻击可在5分钟内成功完成（加快处理速度将使音频中断，使各方可能会怀疑）。伪造数据包的预期128：1或更好的概率现在已经达到1：1。