但是，阅读以下两个出版物后，我对我的解决方案有所担忧：
第一个SSL / TLS漏洞解决方案
SSL / TLS可能允许信息泄露
我不是加密专家，所以我的问题很简单：我是否必须用另一种密码模式替换CBC还是在我的情况下仍然安全？
由于我的应用程序使用C＃中的RijndaelManaged类，因此我的替代方法是：CFB，CTS，OFB。
#1 楼
攻击归因于可预测的初始化向量。如果您对每条消息使用新的随机IV，则攻击不适用。在TLS的1.1之前的版本中，每条记录的IV是前一条记录的最后一个密文块；这可以用来影响服务器使用的IV。
这在一条消息中很好，但是当您继续将密码块从一条消息链接到另一条消息时，就会出现问题。
评论
$ \ begingroup $
好的，谢谢您的回答，但是：我正在使用128位的块大小，这意味着（据我了解...），如果我的应用程序对50KB大小的消息进行加密，则会将其拆分为128-并使用最后一个密文块的IV。我错了吗
$ \ endgroup $
–迈克
2011-09-27 23:06
$ \ begingroup $
@Mike，问题是当您继续将密码块从一条消息链接到下一条消息时，而不是在一条消息中进行链接时出现的。
$ \ endgroup $
– Jeffrey Hantin
2011年9月28日0:00
$ \ begingroup $
这就是我要寻找的重点，也是CBC不“死”的原因。非常感谢！ :-)
$ \ endgroup $
–迈克
2011-09-28 0:14
#2 楼
当攻击者可以在知道要使用的IV的情况下选择部分加密邮件时，就会发生最近的BEAST攻击所利用的CBC漏洞。对于SSL / TLS，数据将分为连续的记录，每个记录本身就是“一条消息”。攻击者产生一些数据，观察相应的记录，并知道该记录的最后一块将用作下一条记录的IV。如果每个“消息”都经过加密，则不会发生此问题。使用新生成的IV，使得攻击者无法预测IV的生成过程。这是TLS的较新版本（从TLS 1.1开始）的功能，并且他们对CBC感到非常满意，这对Disco来说并不致命。
评论
这个问题的公认答案似乎根本没有指定密码模式。它使用默认值，以我的经验，这是与加密相关的所有事情的最佳做法，除非您清楚自己在做什么以及为什么这么做。您是否有理由需要指定密码模式？您提到的解决方案中的默认密码模式是CBC，因此如果CBC不安全，它可能会遇到相同的问题...
在那种情况下，您可以打赌MSFT将解决此问题，方法是弃用旧的类，然后替换为新的类（可能），或者更改默认类（可能性较小）。将其钉在您自己的代码中使您不太可能受益于他们对默认路径的任何改进。请注意，我并不是说这是别人的问题-我是说加密很难，正确进行加密可能会遇到很多麻烦。我发现更好地利用专门解决问题的人员的工作，而不是自己动手，除非您有特定的需求。
感谢您提供其他信息。我的问题是，我的应用程序与使用其他语言和环境编写的应用程序进行通信。如果我在C＃中更改了密码模式，那么我也必须在所有其他应用程序中更改它。