加密和ByteString边界

J F*_*sch 2 encryption haskell aes

我有以下测试应用程序:

import Codec.Crypto.AES
import qualified Data.ByteString.Char8 as B

key = B.pack "Thisismykey....."

iv = B.pack "0000000000000001"

main = do 
     let myenc = crypt' CTR key iv Encrypt (B.pack "1234567812345678") 
     print (B.unpack myenc)
Run Code Online (Sandbox Code Playgroud)

这将打印以下结果:"\ 250\DC4\DC4\255\223\221C\ETBx\239sF \nuZu"

如果我将明文"1234567812345678"更改为"1234567812345688",我会收到"\ 250\DC4\DC4\255\223\221C\ETBx\239sF \nuUu"

如果我将明文更改为"1134567812345678",我得到输出"\ 250\ETB\DC4\255\223\221C\ETBx\239sF \nuZu"

我现在非常惊讶,因为恕我直言不应该发生输入和输出之间的可预测的相关性.如果我在明文的前面改变了一些东西,那么只有输出的前面受到影响等等.可能是某种方式与字节字符串的8或16字节边界有关,我该如何解决这个问题呢?在这里误导我的是什么?

独立于CTR模式,应该注意到AES与4x4字节阵列一起工作,问题是关于单个阵列的加密.根据我的理解,AES应该执行四轮混合,并且单个字节(16个中的一个)的改变应该导致至少50%的比特不同.因此,在我看来,它可以不是16字节明文末尾的变化恰好改变了密文的结尾和前面的变化改变了前面等等.据我所知,IV只作为一个计数器发挥作用当涉及多个4x4阵列时.

Sat*_*vik 7

它与haskell无关.

阅读http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Initialization_vector_.28IV.29

由于您使用相同的IV在CTR模式下对邮件进行两次加密,因此不安全.阅读有关加密算法的信息,尽量避免编写自己的加密代码,因为它更容易出现安全漏洞.

CTR模式的要求是(key,IV)对应该是唯一的.简单的解决方案是为您加密的每条新消息生成一个新的IV.

[CTR模式安全漏洞的解释] https://crypto.stackexchange.com/questions/2991/why-must-iv-key-pairs-not-be-reused-in-ctr-mode

在CTR模式下F(IV +计数器,键)XOR Plaintext = CIPHER ..所以如果nonce和key保持相同,那么纯文本的F是相同的..所以如果$ C_1 $是$ P_1 $和$ C_2 $的密码然后是$ P_2 $的密码

xor($C_1$,$C_2$) = xor($P_1$,$P_2$) for same (key,IV) pair
Run Code Online (Sandbox Code Playgroud)

支持代码:

import Codec.Crypto.AES
import qualified Data.ByteString.Char8 as B
import qualified Data.ByteString as BS
import Data.Bits (xor) 

key = B.pack "Thisismykey....."

iv = B.pack "1234567891012131"
p1 =  (B.pack "1234567812345678") 
p2 =  (B.pack "1234567812345688") 
x = crypt' CTR key iv Encrypt p1 
y = crypt' CTR key iv Encrypt p2 

main = do 
     print $ BS.zipWith xor x y  
     print $ BS.zipWith xor p1 p2
Run Code Online (Sandbox Code Playgroud)

产量

[0,0,0,0,0,0,0,0,0,0,0,0,0,0,15,0]
[0,0,0,0,0,0,0,0,0,0,0,0,0,0,15,0]
Run Code Online (Sandbox Code Playgroud)

  • @JFritsch查看我提供的stackexchange链接.对于唯一键,IV对,您的密文不可预测.问题是1密文和它的纯文本,当你使用相同的(密钥,IV)对时,你可以预测第二个纯文本的其他密文. (4认同)
  • @JFritsch,您可能对https://www.coursera.org/course/crypto感兴趣.这是一个优秀的免费课程,并深入研究这些主题.您对在CTR模式(以及大多数模式)下如何实现AES的理解不正确.它改变了关键,而不是文本.文本与AES的输出进行异或.键/ IV/nonce中的微小变化会在结果中产生很大的变化.文本中的小变化没有. (4认同)
  • @JFritsch,如果你还没有阅读上面的任何链接,重要的是要考虑CTR模式*是什么*.它的重点是将块密码转换为流密码.所以你基本上问为什么,使用相同的输入,流密码生成相同的PRNG流.答案是因为这是应该做的. (3认同)
  • @JFritsch,这根本不是真的,可以用你编写的代码来证明.神秘主义者在这里绝对正确.您可能希望尝试使用ECB模式进一步探索它,因为它更简单并且更纯粹地演示AES. (2认同)
  • @JFritsch你看过CTR模式的实现吗...你没有改变任何东西......改变纯文本与阻塞密码的输入无关..块密码实际上用密钥加密nonce + counter然后用xors加密纯文本..看到我发布的修改后的答案.. (2认同)