如何修复AES解密密文头部的“垃圾”？

Question

我正在玩由节点的加密模块实现的AES 256。js，以评估我是否可以将其用于特定的数据保护功能，我正在计划将其作为我正在设计的应用程序的一部分。

我试图验证一些加密的任意明文的解密，但我无法获得原始明文和解密结果相匹配，这意味着我的加密、解密或两者都有问题。

据我所知，我最好选择一个随机初始化向量（IV），我使用了crypto.randomBytes（16）-证据表明（留档没有说太多）它需要128位。我显然还需要CBC模式，这是有意义的，因为我的用例要求明文是任意长度的。我也不需要PBKDF2或任何类似的东西，因为我自己选择自己的密钥，这与密码无关。

现在，很明显，其中一些似乎起了作用，但我从解密中获得的明文的前16个字节是“乱码”。直觉告诉我这与填充物、静脉注射或两者都有关系。我不知道为什么我应该选择IV作为解密，但不管怎样，只有部分解密的明文与原件匹配，我不知道为什么。

用代码解释：

var key = fs.readFileSync("/root/key"); // 256 bits worth of key from a 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.");

计算明文。等于（解密（加密（明文））产生false，明文也是如此。toString（“utf8”）==解密（加密（明文））。toString（“utf8”）。如前所述，对解密明文与原始明文的目视检查表明，恢复（解密）明文的前128位存在不同（错误）数据。

这可能与我对在解密阶段使用IV的误解有关，或者与使用两个不同的随机IV有关。

我做错了什么，更重要的是，我没有得到什么AES和CBC模式，如果有的话，没有我必须摸索的一切，以摸索链块密码？

我还尝试过处理涉及的数据类型——使用普通UTF-8字符串而不是Buffer来处理普通和密文，但我上面的代码看起来最短，实际上至少成功地解密了（随后我对结果的断言失败了），而其他一些尝试从底层解密过程中得到了一个实际的“坏解密”错误。

Answer 1

我在稍微不同的背景下观察了同样的问题。别人可能会回答这个问题。

使用AES w/ECB进行加密会导致正确的解密，但当我切换到使用AES w/CBC进行加密时，解密和前几个字节都是垃圾。

这可能是因为您没有正确地将IV馈送到解密API—请查找它是否无效，就像API等待二进制的十六进制字符串一样，只有在使用初始化向量IV对CBC第一个块进行解密时才可以。

Answer 2

IV需要是相同的加密和解密。这通常是通过将随机生成的（未加密的）IV前缀到密文来实现的。对于CBC，IV总是与块大小相同的大小-总是16个字节-解密首先从前16个字节检索IV，然后解密其余的。