这个 CryptoJS AES 加密代码会产生安全输出吗？

Question

我相信因为传递给 AES.encrypt 的密钥是一个字符串，所以该函数会自动生成一个 IV。那么下面的代码是否会生成安全的 string_to_encrypt 加密版本？

pass  = document.getElementById('pass').value; // user entered pwrd    salt  = 'some system determined salt';
its   = 9000 + getKeyIterationModifier(pass); // iterations depend on pass
key   = CryptoJS.PBKDF2(pass, salt, { keySize: 512/32, iterations: its });

encrypted = CryptoJS.AES.encrypt(string_to_encrypt, key.toString());

或者我应该添加“模式”和“填充”值来进一步强化它吗？如果有，目前的行业标准值是多少？

换句话说，我是否应该在理想情况下使用 以下的东西（如果是自动完成的，也许没有 iv），如果是这样的话，什么是理想的：

key = CryptoJS.enc.Base64.parse(key);
encrypted = CryptoJS.AES.encrypt(string_to_encrypt, key, {
    iv: iv, 
    mode: CryptoJS.mode.CBC, 
    padding: CryptoJS.pad.Pkcs7
});

Answer 1

CryptoJS.AES.encrypt 使用 EVP_BytesToKey 将传递的“密钥”（视为密码）扩展为实际的 AES-256 密钥，如果“密钥”是字符串，则为 IV。它为此使用随机盐，因此密文是随机的。在您的第二次 sn-p 中，您需要自己处理 IV。

您实质上要问的是 EVP_BytesToKey 是否是安全密码扩展功能。这不是可以轻易回答的问题。它使用 MD5 的事实意味着第一个 sn-p 至少具有 AES-128 的安全性，这应该是好的。

另一个问题是，对于绝对每个加密，IV 都应该是不可预测的（阅读：随机）。不要使用静态 IV，因为这会使密码具有确定性，因此在语义上不安全。观察密文的攻击者可以确定之前发送相同消息前缀的时间。这个建议是在第一个 sn-p 中给出的，但是您必须在第二个 sn-p 中实现该实现，这可能会引入其他问题。

如果您对 CryptoJS 和密码学不满意，请使用第一个 sn-p。否则，尝试改进第二个sn-p。

---

安全注意事项：

如果您在浏览器中仅使用对称加密，您需要在服务器和客户端使用完全相同的密钥。如果您将加密密钥从服务器发送到客户端或以其他方式发送，您需要加密您的对称加密密钥。最简单的方法是使用 TLS。如果你使用 TLS，那么数据和密钥都是加密的，所以你不需要自己加密。这不提供任何安全性，只是有点混淆。你应该阅读：https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

您应该考虑通过诸如 GCM 或 EAX 之类的身份验证模式，或者通过使用具有强 MAC（例如 HMAC-SHA256）的 encrypt-then-MAC 方案来集成经过身份验证的加密。