Cryptography AES计数器模式-加密库已硬编码其初始化向量

我所在的部门需要使用另一个部门编写的加密库，问题是加密库硬编码了AES计数器模式初始化向量（全零）。（基本上，另一个部门拿走了Bouncycastle库，并将自己的坏代码包起来。）我们已经记录了这些权限代码的问题，因此，除非管理层决定采取行动，否则我们将无法使用坏的加密库

我想知道我们是否可以通过在明文前加一个唯一的IV，然后在解密后截断明文的前16个字节来伪造一个正确的初始化向量，例如

ciphertext = encrypt(++sixteenByteCounter + plaintext)
plaintext = decrypt(ciphertext).subArray(16, ciphertext.length)

这对我来说似乎很好，但我几乎不是密码专家

在CTR模式下，您对一系列数字（1,2,3…）进行加密，然后根据该数字对消息进行XORing

众所周知，破解针对重复使用序列的XOR值的加密非常容易。因此，为了避免在CTR模式下出现这种情况，您每次都从一个随机偏移开始（例如，您不是从1开始，而是从75437454896785开始）。这就是CTR模式下的“IV”。这不像是在锁链上的静脉注射。这是一个数值偏移量，从这里开始计算

请参阅-IV是“nonce”（计数器中的高位）

您的建议似乎基于CBC模式或类似模式，其中IV用于损坏下一个块，而下一个块又用于损坏下一个块，依此类推。但这与在CTR模式下使用IV的方式完全无关

您的修复不会改变所用数字的起始点，并且您的消息将非常不安全。请不要这样做

此外，还有一个与stackoverflow等价的加密，在这里您应该真正询问这类问题

但是等等。现在我想到这个。。。我不知道有问题的API。可能只是没有使用IV（可能API中的IV只用于在CBC中完成的链接类型）。柜台有多宽？是否API希望您以随机偏移量启动计数器？我想不是，但你真的需要阅读文档/代码才能确定（我知道我在这个问题上被PyCrypto咬了一口）

---

但无论如何，您的修复肯定不是修复（不幸）。

不，截断任何东西都不会有任何好处：）。IV用于链接模式并参与加密。@EugeneMayevski’EldoSCorp IV通常也用作计数器模式加密中nonce的初始值。我认为问题在于通过预先设置一个值来获得更高的安全性，而不是截断解密后的明文。这对你没有任何好处。每个消息的计数器顶部96位必须是唯一的，否则消息之间的简单异或将破坏您的数据。添加要加密的垃圾在这里没有帮助。必须改变执行情况。