问AES CBC需要多个iv，可以通过使用产生的密码文本16字节作为下一个iv来避免创建重复的iv？

EN

您确实可以避免为每个块提供一个显式IV，而使用前一个加密的最后一个密文块确实是一种方法。但是：

• 您几乎肯定需要经过身份验证的加密，它不仅提供机密性，而且还提供消息的真实性。阅读EFail攻击，其原因之一是基于CBC的加密软件不能保护密文不被篡改(或者更准确地说，它是以一种不适当的方式进行的)。
• 一旦添加了消息真实性要求，就很难避免密文扩展(密文比明文长)，因为实现它的一般方法需要为每个块包含一个消息真实性标记。您可以通过增加每个加密块的大小来调整开销，但这当然会增加加密/解密一个块所需的内存。

请注意，您想要做的事情有无数的缺陷，如果您使用由密码专家编写的库，或者至少复制他们的一个设计(并成功地复制)，那么风险就小得多。例如，流行的library库的最新版本包括加密流和文件加密模块，该库旨在安全地执行这种经过验证的常量内存块加密，但要小心执行：

此高级API使用秘密密钥加密消息序列，或将单个消息拆分为任意数量的块，并具有以下属性：

• 消息不能被截断、删除、重新排序、复制或修改，除非解密函数检测到这一点。
• 同一序列加密两次将产生不同的密文。
• 每个加密消息都会添加一个身份验证标记:流损坏将被早期检测到，直到结束时才会读取流。
• 在计算身份验证标记时，每条消息都可以包含额外的数据(例如:时间戳、协议版本)。
• 消息可以有不同的大小。
• 流的总长度或单个消息的总数没有实际限制。
• 棘轮:在流中的任何一点上，都有可能“忘记”用于加密先前消息的密钥，并切换到新密钥。

此API可用于安全地向对等方发送有序的消息序列。由于流的长度是不受限制的，因此也可以使用它来加密文件，而不管它们的大小。它透明地生成非key并自动处理键旋转。

基于CBC的方法并不能实现所有这一切。

尽管如此，为了理论上的考虑，避免CBC中密文扩展的另一种方法是使用第二个密钥和欧洲央行加密来从计数器或当前生成隐式IVs。首先生成和共享或派生两个分组密码密钥k_1 (用于IV生成)和k_2 (用于加密)和一个公共的\mathrm{IV}。然后，对于每个编号的块m_1, \dots, m_n，您可以这样加密每个块：

由于接收方知道k_1、k_2和\mathrm{IV}，并且也可以计数，因此它们可以重构\mathrm{IV}_i值，而不必由发送方传输。

• 首先，AES!=Rijndael。我假设256是关键尺寸。
• 是的，在CBC模式下的IV不能被重复使用，实际上，它更多的是，IV必须是不可预测的。
• 让我们记住如何在CBC模式下执行加密；\begin{align} C_1 &= Enc_k(P_1 \oplus IV)\\ C_i &= Enc_k(P_i \oplus C_{i-1}),\;\; 1 < i \leq nb, \end{align}，其中nb是块的数量。IV用于第一个块，其余加密使用IV的前一个密文，链接。因此，每个密文都取决于先前密文的输出，期望第一个密文使用IV，我们也可以从方程中看到这个链接；

• AES CBC需要多个iv，可以通过使用产生的16字节密文作为下一个iv来避免创建重复的iv？

CBC需要一个新的不可预测的IV来进行新的加密，它可以是多个块，并且需要填充。

• 我的问题是，是否可以避免为每个块添加16字节长的随机IV，也许我们可以对第一个块使用一个完全随机的IV，对于下一个块可以使用该块的前16个字节作为iv。

如果你仔细看，实际上这就是CBC模式所做的。

• 分成几个部分并继续(更新的问题)

只需使用最后一个密文块作为下一部分的IV。将加密和继续分割是没有错的。

• 还有一条通常的建议；

CBC模式过时，只能提供机密性。在今天的标准中，我们使用了AES-GCM和Chacha20-Poly1305等认证加密模式，可以提供完全的机密性、完整性和身份验证。

您还可以将文件分解为AES-GCM或其他模式(如；

)的一部分。

假设您将文件划分为n部件。使用AES-GCM加密它们中的每一个，并添加以下内容。在加密前为每个部分加上前缀如下；

• 以部件号作为i:n前缀为每个部件
• 在除第一个部分之外的每个部分加上前一部分的身份验证标记。

有了这些，您现在有一个链，可以控制后，解密。你可以检测，添加，删除。订单在您的控制之下，您可以发送，即使没有订单。但是，您需要检查前缀。

您还可以

• 添加零件大小，以及
• 如果您害怕重放攻击，也要添加加密时间。