据我所知，CBC是AES分组密码最安全的操作模式（如果可以这样说的话）。
它只需要一个TRND IV，并且没有损坏。如果您将它与一个不错的HMAC配对，我想它至少和AES-GCM一样安全。
为什么为什么要选择AES-GCM并取消对CBC的支持？
#1 楼
简短：TLS协议中的CBC模式存在安全性问题，必须进行重新设计。结合了不错的HMAC的AES-CBC模式可以像AES-GCM一样安全。但是，实践证明，将密码和MAC安全地结合起来比说起来容易得多。此外，AES-CBC模式所需的填充使事情变得复杂。
特别是，在SSL和TLS协议的历史记录中，由于滥用CBC模式或在CBC和MAC的组合中，例如BEAST和Lucky13。
在Lucky13攻击（由MAC-then-encrypt引起的定时预言）之后，人们认为TLS应该更改操作的顺序。更改操作顺序可能会影响与以前实现的向后兼容性，因此，毕竟认为仅切换到经过身份验证的加密更为实用。
除了安全性方面，还有其他一些方面AES-GCM相对于AES-CBC和HMAC的实际好处：
在大多数具有硬件加速或AES-NI指令的平台上，AES-GCM比具有HMAC的AES-CBC快许多倍。这是因为AES-GCM被设计为具有更高的可并行性。
随机比特的生成相对较慢。这也是AES-GCM擅长的地方。与AES-CBC（在TLS 1.1+中）相比，几乎不需要随机位。
平均而言，AES-GCM不会像AES-CBC，HMAC和填充的等效组合那样扩展消息的大小。 br />
评论
$ \ begingroup $
您是否知道任何实施TLS实际上利用AES-GCM并行处理单个消息的情况？您知道为什么从未将密文窃取视为解决CBC填充问题的方法吗？
$ \ endgroup $
– Ruggero
17-10-27在9:59
$ \ begingroup $
@Ruggero：实际上在一个CPU内核中对单个消息使用并行化（即并行计算多个块）实际上是很常见的。我不知道某些软件实现是否使用多个内核来处理同一条消息的各个部分。密文窃取有助于填充，但不能消除CBC模式的其他缺点。它还可能增加更多的复杂性：仅当数据大于单个密码块时才使用密文窃取（在TLS中不应该考虑）。看来CBC-CS几乎不会提供超过GCM的优势，但需要进行很多更改。
$ \ endgroup $
–user4982
17-10-27在15:45
$ \ begingroup $
我了解CBC-CS，谢谢。对于并行化，我没有关注，您是指SIMD吗？您能否指出进行这种并行化的任何TLS实现？
$ \ endgroup $
– Ruggero
17-10-30在8:39
$ \ begingroup $
@Ruggero：可并行分组密码操作模式允许并行处理许多模块（即，不依赖于先前的分组密码操作的处理，从而使过程顺序进行）。当有大量数据，并且并行执行/流水线化多个执行单元或AES计算时，这种并行处理可以加快速度。我没有提到SIMD，但是在某些情况下，并行化的实现可能涉及SIMD的使用。在具有AES-NI的典型x86处理器上，所有典型的TLS软件（例如OpenSSL）都将利用流水线实施。
$ \ endgroup $
–user4982
17年10月31日在16:37
$ \ begingroup $
@Ruggero：评论内容不适合长时间讨论。您可以例如增加了关于可并行分组密码操作模式的好处的新问题。英特尔有一份文档《英特尔高级加密标准（AES）新指令集》，从第48页开始描述了如何在英特尔平台上使用可并行操作的模式来提高性能。当使用ARMv8（一种加密扩展）或使用某些专用硬件实现时，也可以获得类似的好处。
$ \ endgroup $
–user4982
17年11月2日在16:37
#2 楼
TLS 1.3是对TLS协议的重新启动，该协议专注于最新的加密技术，而不是向后兼容。现在CBC的安全性不如您想象的那样，其使用方式也是如此。 TLS使它特别容易受到攻击。注意：在TLS中，HMAC身份验证标签是在明文而非密文上创建的。这使TLS易受CBC填充oracle攻击。正如您已经提到的，它需要一个攻击者无法预测的IV，如果不满足此要求，则密码将失败。
AEAD可轻松避免此类攻击（已认证）密码，例如GCM。这些模式带有安全证明（基于安全的分组密码/ MAC算法构建）。这使得它们不太可能容易受到以前在CBC模式下的攻击。由于它们也往往更高效，因此没有理由避免使用已经指定的AEAD密码（例如GCM）。 GCM建立在CTR模式的基础上，因此该密码不需要填充，从而消除了一种可能的攻击媒介。
实际上，人们已经在尝试使CBC成为HMAC的官方AEAD密码。此RFC提案。但是，这种AEAD密码从未超过草案阶段。它仍然需要特殊的IV，效率会降低；如果您的目标是实现TLS 1.3的最高效率和安全性，则没有理由将其包括在内。
评论
$ \ begingroup $
ITYM 1.3是（或实际上是建议）作为重新启动的。 EtM作为TLS和DTLS 1.2的扩展，使其成为7366（2014年9月）的标准，但除gnuTLS之外，我不知道它的任何实现。 （尽管有一个错误提示，表明某个地方有多个实现。）
$ \ endgroup $
–dave_thompson_085
17-10-27在2:35
$ \ begingroup $
评论不用于扩展讨论；此对话已移至聊天。
$ \ endgroup $
–马腾·博德威斯♦
19 Mar 27 '19在18:22
#3 楼
据我所知，CBC是AES分组密码的最安全的操作模式。
我不确定你为什么这么说。但是，过去CBC模式存在一些实际问题：
填充Oracle攻击；正如最初在SSL中设计的（并在TLS 1.2中实现），TLS实施CBC模式（使用填充和HMAC）的方式易于受到各种解密预兆攻击（攻击者在其中修改TLS记录，并观察解密器的反应） 。设计TLS解密器以对不良记录做出统一反应是可能的。
IV选择；很难做到正确。是的，如果您正确选择了静脉注射，那是安全的。
现在，他们可以重新设计CBC和HMAC的工作方式，例如改为使用HMAC密文，使用确定性但不可预测的（对于不知道密钥的人）IV；他们拒绝这样做。
评论
您是否有任何来源声称CBC是最安全的模式？基本上，SSL / TLS通过使用MAC-then-ENCRYPT方法和已知的IV来固定其协议，这对于CBC模式而言尤其成问题。他们解决了v1.1中的后一个缺陷，但是他们没有解决前一个问题（例如，在新版本中），而是决定悄悄地继续前进。在此过程中，当臭名昭著应正确属于TLS及其实现时，他们给CBC模式起了一个坏名字。