使用固定IV（例如0块）。
解密之前，请忽略第一个块。
在安全性上与使用随机IV完全相同吗？
另外，如果我在第2步中使用消息计数器而不是随机块，会有所不同吗？
#1 楼
该方法的安全性与普通CBC相同。您的第一个纯文本块$ IV ^ \ prime $的方案显然与带有$ IV = AES（IV ^ \ prime）的普通CBC相同。 $。由于分组密码是对一个分组的排列，因此均匀随机的第一个明文分组将导致正常CBC的均匀随机IV。
用您的方案产生的密文与普通密码具有相同的性质。 CBC。也就是说，您可以使用算法解密普通的CBC密文，也可以使用普通CBC解密由算法产生的密文。
该方案的唯一缺点是，每条消息需要一个额外的AES调用。密文大小没有区别，而且一次调用也没有CPU成本。
一个有趣的问题是，唯一但并非不可预测的IV会发生什么。我怀疑您的计划在这种情况下是安全的，这与正常的CBC不同。但是我没有证明。
#2 楼
如果查看CBC图，您会发现拥有固定的IV等同于使第一个密文块成为IV。如果您的密码是一个很好的伪随机排列，那么，并且仅当所有时间戳都是唯一的，并且“新IV”是唯一且不可预测的时，您的操作才起作用。
事实上，如果您不使用第一个块（“ IV”）的解密值，那么在理想密码模型中，这与普通CBC一样安全，证明如下： CBC的IV要求（唯一性和不可预测性）恰好与伪随机排列的作用相吻合。
如果您使用该值，我不确定。我认为它仍然是安全的，但无法想到一个令人信服的论点，为什么它现在是（或不是），也许有人可以完成此操作。
您还可以将“固定IV”设置为零。为了方便起见-它的值无关紧要。
那就是说，可能最好是修复您的IV传输，只是要做得很干净，而不必解释您怪异的IV技巧。毕竟，如果您可以传输密文，那么IV为什么不能这样做？
评论
$ \ begingroup $
+1修复IV传输。如果可以传输密文，则可以传输IV。只需将IV附加到密文，然后在另一端将其解压缩。
$ \ endgroup $
–斯蒂芬·托瑟（Stephen Touset）
13年1月20日，1：12
$ \ begingroup $
另外，请确保您的时间戳是唯一的。如果它们只精确到一秒钟，那么您可能会生成带有相同时间戳的消息，这可能非常糟糕。您还可以在每条消息中插入一个随机的，未使用的随机数，但是您也可以只使用动态IV。
$ \ endgroup $
–斯蒂芬·托瑟（Stephen Touset）
2013年1月20日，1：15
$ \ begingroup $
密文使用Web服务以数据结构传输。因此添加IV迫使我更改了Web服务...而我并不是唯一使用此Web服务的人。
$ \ endgroup $
–user687254
13年1月20日在18:48
$ \ begingroup $
因此，请将IV附加到密文条目的开头。它的长度是固定的，因此以后可以明确地从正面剥离。
$ \ endgroup $
–斯蒂芬·托瑟（Stephen Touset）
13年1月21日在20:05
#3 楼
当然可以，但是您实际上只是将密文的第一个块用作IV。如果您选择第一个明文块作为运行中的消息计数器（您也可以这样做；比生成随机块要容易得多），并且“丢弃的IV”全为零（反之亦然），则您的方法等效于标准CBC模式，并结合了NIST附录C中所述的IV生成的“加密计数器”方法SP 800-38A：“有两种建议的方法用于生成不可预测的IV。第一种方法是在用于加密IP的同一密钥下应用前向密码功能。随机数必须是加密操作每次执行时唯一的数据块，例如，随机数可以是附录B中所述的计数器或消息号，第二种方法是使用FIPS认可的随机数生成器生成随机数据块。“
n因此，只有在第一个明文块中的随机数超出了攻击者的控制范围时，此方案才是安全的。如果攻击者可以选择随机数，他们可以轻而易举地破坏此方案，例如只要由Rogaway在本文的第4部分中提供。
只要可以保证随机数的唯一性，就可以通过使用单独的独立加密密钥将随机数转换为IV来阻止此类攻击。但是，如果存在攻击者完全控制随机数的风险，则通常很难保证唯一性。在那种情况下，唯一的解决方案（除了首先消除攻击者影响随机数生成的可能性）是切换到耐随机数滥用的加密模式，例如SIV。
评论
$ \ begingroup $
如果我将所有零与消息计数器组合在一起，IV怎么会不可预测？
$ \ endgroup $
–约书亚
2013年1月9日在16:34
$ \ begingroup $
@Joshua：当它通过分组密码时，它变得不可预测（对于不知道密钥的对手）。
$ \ endgroup $
–伊尔马里·卡洛宁（Ilmari Karonen）
2013年1月9日在16:43
$ \ begingroup $
请注意，这是假设对手没有对块密码的oracle访问权限。即使对手确实具有高级CBC模式加密功能的访问权限（即，他们可以请求对选定的明文进行加密），只要对手无法预测IV，CBC模式也可以阻止他们将选定的输入直接提供给分组密码。 。因此，对于使用这种IV生成方法的IND-CPA对手攻击CBC模式，预测IV和oracle对块密码的访问的能力基本上是相同的-一个暗示另一个。
$ \ endgroup $
–伊尔马里·卡洛宁（Ilmari Karonen）
2013年1月9日在16:51
$ \ begingroup $
因此，我要理解的是，当您提到无法预测IV时，您的意思是第一个密文块（其明文与递增的IV（或其他值）进行异或运算）之间是不可预测的加密运行，不是使用的IV足够不可预测吗？就目前而言，如果我将明文中使用的（递增）IV与密文一起传递，则前夕将能够看到IV可以明确预测，但最终的第一个块仍然不是。
$ \ endgroup $
–约书亚
2013年1月9日在21:51
$ \ begingroup $
@Joshua：在您所描述的方案中，第一个密文块实际上是消息其余部分的IV。 （这就是CBC的工作方式：实际上，每个密文块都用作下一个块的IV。）即使第一个明文块（或与其进行“异或”处理的“真实” IV）也无法预测，因为它是通过使用未知（对于攻击者）密钥进行加密的明文获得的。
$ \ endgroup $
–伊尔马里·卡洛宁（Ilmari Karonen）
2013年1月9日在22:44
#4 楼
适当的预防措施，这是实现CBC的可接受方法（是的，它与CBC的更传统的实现方式互操作，至少与将IV直接放在密文前面的CBC的实现方式互操作。）适当的预防措施是确保在加密方向上，与垃圾块互斥或的iv的值不是您在前一个块中使用的值（或者至少是完全不可能）。如果始终使用相同的IV，则可以使垃圾块成为递增计数器；如果您将最后一个密文块用作IV，那么几乎所有与先前加密不相关的垃圾块都将起作用。
现在，为什么要用这种方式实现CBC？好吧，我个人遇到了两种不同的情况，这些技巧可以帮助您解决此问题：
您正在使用加密硬件，该硬件始终坚持使用上一条消息中的最后一个密文块。现在，我们知道使用可预测的IV可能是不安全的。此技巧使我们能够在不继承潜在安全问题的情况下使用此类硬件。
您正在使用可以向量化CBC模式的硬件（因此，加密101个块的消息并不比加密100个块的消息贵很多。 ）。在标准CBC模式下，我们需要生成不可预测的IV。加密安全的RNG至少要昂贵一些，至少比将随机数写入垃圾块并要求硬件再加密一个块要昂贵。
#5 楼
当然可以，而且可以正常工作，但是为什么要这样做呢？它并没有节省房屋的通信端，因为您仍然需要通信垃圾密文块。在计算方面，如果您解密该垃圾块并将其丢弃，那么您将真正不需要进行对块密码操作的另一次调用。
计算机，这不是什么大问题，但是如果您使用的是计算能力较低的设备，则对块密码进行额外的调用会增加一些不必要的延迟。
评论
$ \ begingroup $
我想它应该节省将IV发送出去的时间，但是对加密/解密例程的不必要的调用可能会浪费得无法接受
$ \ endgroup $
–约书亚
13年1月8日在19:57
评论
$ \ begingroup $
我假设，只要加密块的数量低于生日限制，该方案就可以通过可预测的IV（例如计数器）来确保安全。这个想法是，AES原语将永远不会对同一块进行两次加密。但是，发生碰撞时的故障可能更严重。
$ \ endgroup $
– CodesInChaos
2012年11月19日在11:53
$ \ begingroup $
@CodesInChaos CBC加密在达到生日边界时已经失败，因此应该在此之前重新输入密钥。
$ \ endgroup $
–黛米
19年1月14日在5:59
$ \ begingroup $
一个相关安全性定理的证明，其中IV是一个反例：crypto.stackexchange.com/a/67296如果读者随意选择IV进行练习，则应进行调整以考虑IV碰撞的可能性。
$ \ endgroup $
–吱吱作响的s骨
19年3月12日在18:13