对GCM持消极态度。我一直从以前的阅读中想到，GCM是当前高效，安全，易于使用的AES模式的黄金标准？ />：但是CTR + HMAC实际上是一种组合的经过身份验证的加密模式。如果您具有使用CTR + HMAC的操作系统，我建议您不要花费精力切换到GCM，这实际上很难解决。 ？ poly1305-chacha20现在不应该使用，因为它在成本上便宜很多，并且密钥更小（32字节）？
另外，chacha的代码也很容易获得。 br />
tptacek：我个人绝对喜欢ChaCha / Poly，而不是GCM，但是不幸的是，GCM现在很流行。在NIST资助的无障碍AEAD中，它的性能非常出色，因此得到了广泛实施。努力切换。让我感到困惑的是，他说GCM“实际上很难正确解决”。是什么使GCM模式比CTR + HMAC难？
#1 楼
有关GCM实施的“难点”是抵抗边信道攻击，尤其是基于缓存的攻击。 GCM是AES-CTR和依赖于二进制字段中的乘法的自定义MAC的组合（GF（2128））。该操作的有效实现通常使用表，这可能会导致缓存定时攻击，因为所访问的表插槽将取决于秘密数据（尽管据我所知，缓存定时攻击从未被“发现”，如果最近使用的x86 CPU足够多，则可以使用AES-NI操作码，它对AES有所帮助用于二进制字段的乘法运算，这使得GCM既可以抵抗旁通道泄漏，又非常高效。但是，较小的设备并不一定具有这种硬件辅助实现的奢侈性。实际上，可能有人会争辩说，与大型PC相比，小型嵌入式CPU（例如，低端32位ARM CPU）上的性能更有可能成为问题，而大型PC上的加密仅使用了少量可用计算
对于小型CPU，Poly1305 / Chacha20将更快，占用空间更小，对旁通道攻击的抵抗力更强。进行AES的恒定时间实现的技术仍然适用（例如Kasper-Schwabe实现），但由于32位小型CPU仅具有32位寄存器（Kasper-Schwabe代码使用位片化技术来运行），因此性能较低。在128位寄存器上有8个并行AES实例，但在32位寄存器中，这下降为2个并行AES实例。对于二进制字段部分，可以使用纯整数乘法，但是为了避免进位问题，大多数位被清除了，因此与使用基于素数字段的MAC（例如Poly1305）相比，会有更多的乘法。
GCM之所以存在，是因为它获得了NIST的祝福，从而达到了许多标准。它甚至说服CPU供应商加入专门的操作码，这反过来将巩固其地位。 。因此，尽管由于实施问题而对GCM有点不满意，但继承仍然是公开的。 Poly1305 + ChaCha20首先出现在这里有点领先，但这并不能使其自动回退。
GCM和Poly1305 + ChaCha20的共同问题是需要非重复IV。在流式协议（例如SSL / TLS）的上下文中可以轻松管理这样的IV，但是它可能是加密独立消息的麻烦之源-IV重用是一种致命的错误，在给定条件下不容易测试实施。无IV加密系统将需要采用两次通过的方法（这不一定是加密消息的问题）。可能的候选者将是一种反直觉的MAC-then-encrypt构造，（例如）在明文上计算HMAC，并将HMAC值用作AES-CTR加密的IV。
评论
$ \ begingroup $
有什么理由正确生成随机的128位值不能解决非重复IV问题吗？除了比其他方法慢？
$ \ endgroup $
–安东尼·卡夫（Anthony Kraft）
16年4月11日在15:34
$ \ begingroup $
一个主要原因是，在嵌入式设备上实施加密时，正确生成随机值是最困难的问题之一-尤其是因为无法真正测试随机性的质量。
$ \ endgroup $
–托马斯·波宁（Thomas Pornin）
16年4月11日在15:37
$ \ begingroup $
@AnthonyKraft减轻重复出现的IV问题的另一种方法是抗乱数滥用构造。对于AES-GCM，这以AES-GCM-SIV的形式出现。
$ \ endgroup $
– Xander
16年4月11日在16:00
$ \ begingroup $
请注意，强烈建议您为GCM使用96位随机数/ IV。使用大小不同的随机数存在一些问题，规范甚至建议实现仅支持96位（12字节）的实现。当然，这是针对此答案下方的第一个评论发布的，提到的是128位值而不是96位值。
$ \ endgroup $
–马腾·博德威斯♦
16-10-30在16:51
#2 楼
发生了不同的论点，部分涉及到上下文猜测。使用CTR + HMAC的论点基本上是：
切勿更改正在运行的系统（不需要）。
CTR + HMAC的安全性本身很好。如果您有一个良好的，可行的实现方式，并且计算复杂性不会给您带来麻烦，则应保持现状。
使用GCM和ChaCha / Poly
我个人绝对比GCM更喜欢ChaCha / Poly，但是不幸的是，GCM现在很流行。 NIST所支持的无障碍AEAD的性能非常出色，因此得到了广泛实施。 。 ChaCha / Poly尚未获得NIST的认可，因此可能无法在某些szenarios中使用。就像报价中所说的那样。有很多理由更喜欢这两种。尤其是有充分的理由（某些语言没有可用的强化库）更喜欢AES-GCM。密码库的条款。由于您不打算自己动手，对于仅使用加密库的开发人员来说，这可能不会有任何意义。当然更容易正确，不会在执行这些错误时造成致命的错误。这是选择具有较少实现花絮的密码的一个很好的理由。可能需要更多上下文。
评论
$ \ begingroup $
我还假设GCM复杂性是库作者与库用户之间的一种。不幸的是，讨论没有进一步的内容，因此，除非其他人可以提出一些与CTR + HMAC上GCM使用相关的致命问题，否则我们将不得不请作者自己进行澄清。
$ \ endgroup $
–安东尼·卡夫（Anthony Kraft）
16年4月11日在15:28
评论
您缺少一个重要的事实：推荐做什么用？在安全性，实现简便性，运行时复杂性，...方面要实现什么...@SmokeDispenser好的。以一个典型的SaaS应用程序为例，该应用程序希望对服务器上某些存储介质中的某些用户数据进行加密。应该尽可能快地运行，但是到最后，由于它们不在嵌入式设备上，因此它们可以承受一些周期。易于实现至关重要，因为大多数后端开发人员都不会成为加密专家。可能不是试图防范州级的对手，但如果这样做的话，那就更好了。