如何解決AES解密密文（Node.js加密）的頭部「垃圾」？

我正在使用由Node.js中的本機「加密」模塊實現的AES 256。目前試圖驗證加密明文的解密，一個任意字符串（見下文）。根據我的理解，我最好選擇一個隨機初始化向量，我使用crypto.randomBytes(16) - 證據表明（文檔沒有說太多），它需要128位。我也顯然需要CBC模式，這很有意義，因爲我的明文通常是任意長度的。我也不需要PBKDF2或類似的東西，因爲我自己選擇我自己的密鑰，而這根本不是密碼。如何解決AES解密密文（Node.js加密）的頭部「垃圾」？

我已經設法「排序」讓事情起作用，但解密的密文在前16個字節處出現亂碼。我的預感告訴我這與填充，IV或兩者有關。我不知道爲什麼我應該爲Decipher選擇IV，但無論如何，只有恢復的明文的一部分與原始文本匹配，並且我對此感到茫然。

var key = fs.readFileSync("/root/key"); // 256 bit data file 

function encrypt(plaintext) { 
    var cipher = crypto.createCipheriv("aes-256-cbc", key, crypto.randomBytes(16)); 
    return Buffer.concat([ cipher.update(plaintext), cipher.final() ]); 
} 

function decrypt(ciphertext) { 
    var decipher = crypto.createDecipheriv("aes-256-cbc", key, crypto.randomBytes(16)); 
    return Buffer.concat([decipher.update(ciphertext), decipher.final()]); 
} 

var plaintext = new Buffer("Quick brown fox jumps over the lazy dog.");

排序plaintext.equals(decrypt(encrypt(plaintext)))失敗，類似的斷言像plaintext.toString("utf8") == decrypt(encrypt(plaintext)).toString("utf8")以及的斷言。對恢復的明文內容與原始明文的視覺檢查也表明在恢復的明文的前128位有不同的（錯誤的）數據。

這可能與我在解密階段使用IV的誤解有關，或者與使用不同隨機IV的事實有關。

我在做什麼錯誤，更重要的是我沒有用AES和CBC模式得到什麼，沒有標題和鏈接所有關於鏈接分組密碼？

我也嘗試瞭解數據類型 - 使用普通UTF-8字符串替代Buffer用於普通文本和密文，但此代碼看起來最短，實際上至少可以成功解密，而其他一些嘗試可以獲得我「壞解密」錯誤。

來源

2017-08-02 amn

對於加密和解密，IV需要相同。這通常是通過將隨機生成的（和未加密的）IV加密到密文上來完成的。對於CBC，IV的大小始終與塊大小相同 - 總是16個字節 - 要解密首先從前16個字節中檢索IV，然後解密其餘的部分。

來源

2017-08-02 22:30:11

啊，我不得不承認這個想法超出了我的想法。更正了在加密過程中使用IV加密後由'encrypt'返回的密文前綴的代碼，並在解密之前再次將其分開。現在斷言成功了。非常感謝！ – amn

如何解決AES解密密文（Node.js加密）的頭部「垃圾」？

回答

相關問題