• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

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

我的部门在工作中需要使用由其他部门编写的加密库的权力,问题是加密库对其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来解决这个问题的)。

但无论如何,无论如何,你的修复肯定不是修复(不幸的是)。


版权声明:本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系管理员进行删除。
喜欢 (0)