我应该为块密码使用ECB还是CBC加密模式？

#1 楼

两者之间真正区别的真正简单解释是：


ECB（电子密码书）基本上是原始密码。对于每个输入块，您都对该块进行加密并获得一些输出。这种转换的问题在于，明文的任何常驻属性都可能很好地显示在密文中（可能不太清楚），这就是应该再次保护块和密钥时间表的原因，但是分析模式可以推断出您原本以为被隐藏了。
CBC模式是密码块链接的缩写。您有一个初始化向量，您可以对它进行异或处理第一部分明文。然后，您对该明文块进行加密。在加密该块之前，下一个明文块将与最后一个加密块进行异或。

（来自Wikimedia Commons的公共域图像。）

CBC的优点ECB上的功能很多–使用ECB，假设有很多事情，您可以管理部分解密并轻松填充空白，例如，如果从加密的硬盘中提取数据。使用CBC时，如果序列中缺少几个块，则不可能进行加密。但是，CBC有一个缺点-ECB自然支持并行操作，因为每个块都可以独立于下一个进行加密。但是，使用CBC会比较困难，因为您必须等待每个块。 （不过，您仍然可以并行化解密。）

在某些情况下，CBC本身也被认为是易受攻击的，特别是使用可预测的IV和未经身份验证的解密可以使您猜测此答案中解释的纯文本，在这里更详细。

通过使用不可预测的（加密随机）IV，可以解决IV问题。传统上，使用消息身份验证代码可以解决身份验证问题-但是，这些实现并不理想。发明了专用模式也可以解决身份验证问题，例如EAX和Galois计数器模式。

还存在用于处理特定情况的其他模式，例如：



Counter Mode使用了这样的事实，即ECB模式下的分组密码输出应该与随机信号没有区别，并且XOR是将counter + iv组合作为流密码加密的结果。是磁盘加密中使用的一种操作模式。要取消的关键点是，每种模式都有许多优点和实现方面的考虑，必须仔细权衡（并正确实施）。并且，在可能的情况下，请避免使用ECB。典型的ECB加密linux企鹅的图片，但是我被要求扩展“明文中的驻留属性”，因此以下内容将是相同的想法，只是文本形式。如果您不需要它，请随时跳过。

首先，让我们使用一种我了解的格式-mp3帧。像大多数纯文本一样，这远非“无法与随机区分开”-实际上，例如，MP3帧头以11位设置为1开始。

在块级别，操作是确定性的。如果我对“密码栈交换”进行加密，并且该加密适合单个块，则我希望每次给定参数都得到相同的输出。这听起来像是一个疯狂的critera（当然我们需要这个），但值得强调。
在块级别上，输出与随机变量是无法区分的-更正式地讲，攻击者比使用随机置换至少在现实上可计算的方式上没有优势。我的术语可能有点过头，因为我是自学成才，但是我相信，如果优势不为零，那么您会有偏见，这会使密码成为线性密码分析的候选人。

这些语句仅考虑单个块即可应用；但是显然，在现实世界中，我们还需要更多的东西-我们希望对多个块进行加密。

假设我们生活在一个虚构的世界中，人们认为块大小为一个字节的块密码是个好主意。现在让我们想象一下，否则这将是一个完全好的分组密码。现在想象一下，您有一些贾斯汀·比伯（Justin Bieber）音乐的MP3，而您非常希望NSA对此一无所知。因此，您采用分组密码并对MP3进行加密。在MP3中。这些总是在每一帧的开头。现在我们的密码与随机密码是无法区分的，因此我们得到完全随机的密码文，例如0xFF。但这也是确定性的，我们使用的是ECB，因此每个0x1c的帧头都变为0xFF。帧头是如果他们怀疑这是MP3。密码分析有时是关于正确猜测的情况，在这种情况下，正确的猜测将使他们了解音频样本的确切时间，并允许他们识别格式。现在也可以解码。那不是我们打算提供的信息，但是我们做到了。

特别是当您考虑到我们加密的大部分内容都具有严格的数据格式时，此问题很常见。您必须对块对齐进行一些假设，但是数据越大，这个问题越明显。这些是明文固有的结构，并在无意中暴露给攻击者。

CBC模式的最初目的是作为识别损坏消息的一种形式，为此，CBC的安全性是本文处理。我无法通过论文找到该想法的最初实现，但您也许可以找到它。当然，我读过的大多数关于分组密码的书都提到了它和其他问题。

#2 楼

ECB和CBC仅与加密有关。在某些时候，大多数要求加密的情况也需要完整性检查（忽略主动攻击者的威胁是一个常见错误）。有组合的模式可以同时进行加密和完整性。请参阅EAX和GCM（另请参阅OCB，但是此问题有一些挥之不去的专利问题；假设软件专利完全适用于您的情况-一个不重要的问题-然后有一些明确的许可）。 >

#3 楼

切勿使用欧洲央行！这是不安全的。

我建议使用经过身份验证的加密模式，例如EAX或GCM。如果无法使用经过身份验证的加密，请使用CBC或CTR模式加密，然后将MAC（例如AES-CMAC或SHA1-HMAC）应用于生成的密文。

#4 楼

ECB是不安全的，它会泄漏信息。 CBC更好。但是，如果需要随机访问文件，请使用CTR模式。

有关分组密码操作模式的更多信息，请参阅Wikipedia文章。

#5 楼

更好是一个主观术语。但是，对于在ECB和CBC之间进行选择，几乎在所有情况下都应选择CBC。请参阅分组密码作为操作模式的配置选项。操作模式对所得密码的安全性有很大影响。

ECB的问题在于，它实际上不是一种操作模式。它基本上与将纯文本分为多个块并完全彼此独立地加密它们相同。当块密码被认为是安全的时，单个块的结果密文当然也是安全的-当独立分析时。但是，当多条消息或多条消息被加密时，ECB并不安全。相同的明文块将产生相同的密文。这意味着攻击者可以轻松地检测到重复。

CBC通过引入向量来解决此问题，该向量会在第一个明文块被加密之前对其进行更改。结果是整个密文是随机的，因为该块创建的密文被用作下一个块的向量（依此类推）。换句话说：即使每个块包含相同的信息，它也可以确保对每个块进行不同的加密。

除了独特性，IV对于攻击者来说也需要不可预测。这是为了防止攻击者更改明文和IV组合：找到重复的密文将表明以前曾看到过分组密码的输入，因此泄露了有关明文的信息。通常，不可预测的IV的创建是通过使用安全随机数生成器（RNG或RBG）创建的来完成的。由于加密和解密都需要使用相同的，唯一的IV进行，因此IV通常以密文为前缀。随机IV无需保密。

欧洲央行仍然有用吗？本质上，不应将其用于消息机密性。但是，它仍然可以用于加密完全随机的数据（例如对称密钥）或用作更好的算法和协议的构件。仅出于这个原因，它几乎仍然存在于几乎所有的加密API中。 ECB或CBC都不提供完整性或身份验证。这意味着，即使没有额外的保护，即使CBC也不适用于传输协议。任何人都可以更改消息，并且如果可能进行填充oracle攻击，则很可能也会失去机密性。否则，您可以同时在IV和密文上执行HMAC。

#6 楼

CBC比ECB更好。与y的密文相同。因此，攻击者可以轻松地进行密码分析。

但是
如果使用CBC，则x的密文与y的密文会有所不同。因此，攻击者可以进行密码分析困难。

#7 楼

长话短说，如果有很多重复的数据不使用ECB，则会出现一个明显的模式，CBC更安全，但运行更重，因为每个块都是另一个块的密码

#8 楼

例如，如果您只加密一个块，则最推荐使用ECB模式。例如，如果您有两个数据块，并且您使用的是ECB模式，则检测纯文本的机会更大。 br />第一个块的加密输出可以用作加密第二个普通块的密钥。

#9 楼

该问题的问题在于该问题不完整。这就像在问“我应该用锤子还是螺丝刀”这样的问题。在不了解基本应用程序和要求的情况下，不可能正确地回答这个问题（实际上，答案可能是“卷尺”）。如果您有精简加密要求（例如，快速简便），则ECB很有用。如果您正在寻找更强的力量，那么您需要考虑CBC。但是，如果必须处理数据丢失，则CBC变得非常困难（在丢失点之后，您将无法恢复数据块）。如果您需要处理数据丢失，强大的加密和相对快速的处理，则可能需要使用其他技术（并且有很多技术）。

另一个优势/劣势比较是随机访问/并行处理。 ECB块可以并行加密和解密。可以完全随机地访问每个ECB块，并且先前块中的任何丢失或损坏量都不会影响当前块。在CBC中，加密是完全串行的（在对N-1块进行加密之前，您无法对N块进行加密，以此类推，回到第1块）。解密需要2个块（您需要块N-1来解密块N）。因此，CBC中的随机访问需要的数据量是ECB的两倍。首先进行白化过程（使用另一个系统使基础位看起来随机-白噪声）。

总之，欧洲央行本身并没有提供太多安全性。 CBC本身不能提供很好的错误恢复（有些但不是很好）。作为大型系统的一部分，ECB是一个很好的构建块（哎呀，它在CBC中使用）。 CBC非常适用于错误率低且不需要随机访问加密的系统（例如，在写入文件时）。了解这些限制有助于确定使用哪个以及何时使用（或者是否需要完全不同的功能）。