我的部门需要使用由另一个部门编写的加密库，问题是加密库已经硬编码了它的 AES 计数器模式初始化向量（全零）。（基本上，其他部门拿走了 Bouncycastle 库并在其周围包装了他们自己的损坏代码。）我们已经记录了此代码的问题，因此现在除非管理层决定采取行动，否则我们将被困在使用损坏的加密库.
我想知道我们是否可以通过在明文前面加上一个唯一的 IV 来伪造一个正确的初始化向量，然后在解密后截断明文的前 16 个字节，例如
ciphertext = encrypt(++sixteenByteCounter + plaintext)
plaintext = decrypt(ciphertext).subArray(16, ciphertext.length)
这对我来说似乎很好，但我几乎不是密码学专家
呜呜呜……
在 CTR 模式下，您正在加密一系列数字（1、2、3...），然后对您的消息进行异或运算。
众所周知，根据重复使用的序列来破解 XOR 值的加密是非常容易的。因此，为了避免在 CTR 模式下出现这种情况，您每次都从随机偏移量开始（例如，您不是从 1 开始，而是从 75437454896785 开始）。这就是“IV”在 CTR 模式下的含义。它不像链接中的IV。这是您开始计数的数字偏移量。
请参阅https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29 - IV 是“随机数”（计数器中的较高位）。
您的建议似乎基于 CBC 模式或类似的模式，其中 IV 用于破坏下一个块，而后者又用于破坏下一个块，依此类推。但这与 IV 在 CTR 模式下的使用方式完全无关。
您的修复不会改变所用数字的起点，并且您的消息将非常不安全。请不要这样做。
此外，还有一个等效于 stackoverflow 的加密货币，您真的应该问这种事情。 https://crypto.stackexchange.com/
可是等等。现在我考虑一下……我不知道有问题的 API。可能是根本没有使用 IV（也许 API 中的 IV 仅用于在 CBC 中完成的那种链接）。柜台多宽？可能是 API 期望您以随机偏移量启动计数器吗？我猜不是，但是您确实需要阅读文档/代码才能确定（我知道我被 PyCrypto 的这个问题所困扰）。
但无论如何，无论哪种方式，您的修复肯定不是修复（不幸的是）。