为什么不应该使用ECB加密？

#1 楼

为什么我不应该使用ECB加密？超出其长度，所有接受任意长明文的加密方案都会在某种程度上泄漏。使用ECB模式的明文的基础密码的块大小为（））始终产生相同的密文块。这可以使攻击者能够：


检测两个ECB加密的消息是否相同；
检测两个ECB加密的消息是否共享公共前缀；
检测只要两个ECB加密的消息在块边界对齐，它们是否共享其他公共子字符串；或
检测单个ECB加密的消息是否（以及在何处）包含重复数据（例如长时间的空格或空字节，重复的标头字段或文本中同时出现的重复短语）。在Wikipedia上有一个很好的图形化展示，它利用ECB模式和语义安全密码模式（例如CBC，CTR，CFB或OFB）对相同（原始，未压缩）的图像进行了加密：



虽然这种情况有些虚假（通常不会像这样加密原始图像），但它很好地演示了ECB模式的问题：输入图像中的重复区域会导致ECB模式中的重复模式。加密输出，因此尽管进行了加密，仍然可以识别图像的许多大型特征。在现实世界中，攻击基于ECB的加密方案的密码分析者更有可能在密文的十六进制转储中查找此类模式，但是原理是相同的。

如本答案所述，2013年Adobe密码数据库泄漏给出了ECB加密导致实际数据泄露的弱点的实际案例。在此，导致泄漏严重性的一个因素是，Adobe没有使用适当的哈希算法对它们进行哈希处理，而是使用ECB模式对密码进行了加密。这使攻击者可以快速找到多个帐户共享的密码，或与其他密码（例如password1和password2）共享通用前缀，还可以揭示每个密码的大致长度。 ECB加密模式还具有其他弱点，例如，它具有高度的可扩展性：由于每个明文块都是单独加密的，因此攻击者可以通过将以前观察到的密文块拼凑在一起来轻松生成新的有效密文。

但是，可延展性仅是在未使用消息验证码的情况下使用ECB加密，并且在这种情况下，由所有其他未经身份验证的加密模式（在某种程度上）共享的（如上述CBC， CFB和OFB。因此，即使使用ECB模式时，它确实往往是一个额外的问题，但它实际上并不能被认为是ECB模式的特定弱点。


我应该使用什么代替呢？ />
您应该使用任何经过身份验证的加密模式，例如GCM，EAX或OCB。

个人而言，对于短消息，我比较喜欢SIV模式（RFC 5279），提供了一层额外的耐滥用性。 （如果不小心使用相同的IV /随机数来加密多个消息，则许多其他加密模式将严重中断。在这种情况下，SIV模式将保留其所有安全属性，但泄漏的加密消息是否相同。）

您还可以使用任何传统的语义安全加密模式（例如CBC或CTR），并使用Encrypt-then-MAC结构将其与消息身份验证代码（例如HMAC）结合使用。 （也就是说，您应该首先对消息进行加密，然后计算密文的MAC，然后将其附加到密文中。）只要您确保在尝试对消息进行解密之前先验证MAC，这种构造就可以防止对于主动（选择密文）攻击，这些模式存在各种漏洞。为此目的而设计的密码模式，例如XTS。请注意，此类模式通常缺乏对主动攻击的抵抗力，并且可能存在其他弱点，在使用它们之前应予以理解。如果可能，应将它们与某种形式的完整性保护（例如，哈希树上的MAC）结合使用。

#2 楼

您不应该使用ECB模式，因为它将加密相同的消息块（即每次调用块密码时加密的数据量）为相同的密文块。这是一个问题，因为它将显示相同的消息块是否已多次加密。 Wikipedia很好地说明了此问题。

#3 楼

就像@Guut Boy提到的那样，从某种意义上说，如果对具有相同块的消息进行加密，那么攻击者仅通过观察CipherText即可获得一定的优势来获取纯文本信息。 br />最好使用CBC模式来加密长消息。此模式引入了一个称为IV（初始值）的附加参数，您可以使用会话号进行初始化，以防止在两次加密同一条消息的情况下受到攻击。