我想我的问题的要点是：是否存在 CBC 比 GCM 更好的情况？
我问的原因是通过阅读Matthew Green 的这篇文章，关于密码学堆栈交换的这个问题，以及对 XML 攻击的解释（因为我在我的工作中加密了 json，虽然它没有在任何地方流式传输，但是显然选择的密文攻击是可能的），那么我永远不应该使用CBC，而只使用GCM。
换句话说：没有理由使用 CBC，只要 GCM 存在（它在 OpenSSL 上执行，我用于加密工作的库）。因为：
GCM = CBC + 身份验证。
有人可以告诉我我的结论是否正确吗？
重要更新：由于这个问题变得如此迅速，我想从我的研究中指出GCM 不是银弹。GCM 存在一个巨大的问题，即如果您两次使用相同的 IV，它可能会破坏您的密钥（由于使用 GMAC，所以它不是万无一失的）。如果你是偏执狂（像我一样），如果一个人想要安全起见，带有 HMAC 的 CBC（加密然后 MAC ）可能是最好的。（如果我在此更新上错了，也请纠正我）。
CBC 和 GCM 完全不同。正确使用时两者都是安全的，但 CBC 不能并行化并且缺乏内置身份验证。因此，CBC 仅适用于加密不需要随机访问的本地文件。
至于它可能具有的任何优势，如果重复使用 IV，CBC 不会像灾难性地失败，如果在基本硬件上实现它会更快。
至于 GCM，它基本上是 GCM = CTR + Authentication（不是 CBC）。如果使用得当，它既快速又安全，而且用途广泛，因此很受欢迎。
大挑剔：
GCM = CBC + 身份验证。
不，GCM = CTR + 身份验证。
但总的来说，你是对的；CBC 是一种较旧的模式，它是在密码学意义上的黑暗时代（不迟于 1970 年代）发明的，现在由于缺乏内置的身份验证以及填充预言所引起的所有问题而受到反对。一个很好的实际例子是 TLS 1.3 摆脱了对 CBC 的支持。
然而，GCM 也不是灵丹妙药。严格来说是正确的，但在实践中证明自己远非万无一失：
CBC没有这些问题。随机 IV 工作得很好（实际上是必需的），如果你确实重复了一个 IV，你不会遇到灾难性的失败，你只是泄露了关于相等的明文前缀的信息。
简单地说 - CBC 排在第一位。您可能拥有仅支持 CBC 的系统。
这与“如果 AES 和 SHA-2 可用，我为什么还要使用 RC4 和 MD5？”的问题相同。兼容性和历史。（与许多其他密码选择相同。）
如果您的所有系统都支持 AES-256-GCM，并且有运行它的资源，并且有更高的安全需求，那么请使用 AES-256-GCM。
例如，我的系统不支持任何比 SSL3、RC4 和 MD5 更新的具有 1024 位证书的系统。（在 2018 年，是的）。当然，现在这并不比 ROT13 好多少，但它对于实际上不需要任何加密的数据已经足够了。（现在人们把这些东西称为物联网。）