AES计数器模式 - 加密库对其初始化向量进行了硬编码

  • Z时代
  • 2024-01-10
  • 分类：问答

我的部门在工作中需要使用由其他部门编写的加密库的权力，问题是加密库对其AES计数器模式初始化向量（全零）。 （基本上，其他部门采用了Bouncycastle库，并在其周围包装了自己的破坏代码。）我们已经记录了代码中存在的权限问题，所以现在除非管理层决定采取行动，否则我们会使用破坏的加密库。AES计数器模式 - 加密库对其初始化向量进行了硬编码

我想知道我们是否可以伪造一个适当的初始化向量，方法是在明文前加一个独特的IV，然后在解密后截断明文的前16个字节，

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

这似乎没什么问题，但我绝对不是一个加密专家

回答：

Noooooo ....

在CTR模式下您要加密的数字序列（1,2,3 ...）然后对你的消息进行异或。

这是出了名的容易开裂加密，针对一个再次使用序列异或值。因此，为了避免在CTR模式下出现这种情况，您每次都要从随机偏移开始（例如，您不是从1开始，而是从75437454896785开始）。这就是CTR模式下的“IV”。这不像是链接中的IV。这是您开始计数的数字偏移量。

请参阅https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_.28CTR.29 - IV是“nonce”（计数器中的较高位）。

你的建议似乎是基于CBC模式或类似的情况，其中IV用于对下一个块进行调整，而后者又用于对下一个块进行调整，等等。但这与在CTR模式下使用IV的方式完全无关。

您的修补程序不会改变使用的数字的起点，并且您的消息将毫无希望地变得不安全。请不要这样做。

此外，还有一个加密等效于stackoverflow，你应该真的问这种事情。 https://crypto.stackexchange.com/

但是等待。现在我想到这个......我不知道这个API。这可能是因为IV没有被使用（也许API中的IV仅用于在CBC中完成的那种链接）。柜台有多宽？难道API会期望你用随机偏移来启动计数器吗？我想不是，但你确实需要阅读文档/代码（我知道我是用PyCrypto来解决这个问题的）。

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

以上是 AES计数器模式 - 加密库对其初始化向量进行了硬编码 的全部内容， 来源链接： utcz.com/qa/262579.html

回到顶部