为什么这个 cCryptoGS AES 加密给出的所有密文几乎相同？

Question

我目前正在使用 Google App Script 试验 AES 加密，并且发现了 cCryptoGS。

感觉很奇怪，因为所有密文似乎都以 U2FsdGVkX1 开头（尽管我将示例中的 this is my passphrase 部分更改为其他内容非常非常不同）。我不确定我是否记错了，我曾经尝试过 AES，但在 Nodejs 上，它看起来有很大的不同，即使我只更改一个字符，我也会得到完全不同的文本加密 /em> 在我的消息或我的密钥中。

即使在How is AES implemented in CryptoJS?这个帖子中，密文也以U2FsdGVkX1开头。

我要问的是：这 cCryptoGS 真的在做它声称要做的事情吗？ （即对消息应用 AES 加密）

这里是网站https://ramblings.mcpher.com/gassnippets2/cryptojs-libraries-for-google-apps-script/网站上也有图表显示Google App Script不能很好地处理复杂的计算，所以看起来合法，但结果似乎如此......奇怪...因为，总体而言，AES 似乎是进行加密的最佳选择之一。

如果这确实是 AES 应该如何工作，有什么方法可以让它看起来更多随机？提前非常感谢你，:(

非常感谢您，

Answer 1

CryptoJS 可以处理密码短语和密钥以进行加密和解密。字符串被解释为密码，WordArrays 被解释为密钥，s。 The Cipher Input.
cCryptoGS 封装了密码变体并支持算法 AES、DES、TripleDES 和 Rabbit，请参阅 Usage。

例如对于 AES，cCryptoGS/CryptoJS 使用 AES-256 进行加密，因此除了明文之外还必须传递密码。
在加密之前，会生成一个随机的 8 字节盐，并从密码和盐中生成一个 32 字节的密钥和 16 字节的 IV，使用 OpenSSL 密钥派生函数EVP_BytesToKey()。
结果以 OpenSSL 格式生成以与 OpenSSL 兼容，该格式由 Salted__ 的 ASCII 编码后跟 8 个字节的 salt 和实际密文组成，整个表达式为 Base64 编码。
Salted__ 的 Base64 编码是 U2FsdGVkX18=，其中 U2FsdGVkX1 是固定的（最后两个字符取决于盐的第一个字节，因此可以更改）。因此，任何加密都以 U2FsdGVkX1 开头，但这不会泄露任何信息。
所以是的，它是用 AES-256 加密的，常量前缀 U2FsdGVkX1 并不重要。

然而，密钥派生函数EVP_BytesToKey() 现在被认为是不安全的，尤其是对于 cCryptoGS/CryptoJS 使用的参数（损坏的 MD5 摘要和迭代计数为 1），s。例如here, 3rd part，因此实际上不推荐使用它（可能是为了兼容性）。
这适用于使用密码短语进行加密/解密的包装功能。 cCryptoGS 还直接允许使用 CryptoJS 函数，请参阅 CryptoJS direct，其安全性将单独评估。

安全的方式是直接传递密钥和IV，或者在使用密码短语时不应用内置函数EVP_BytesToKey()，而是应用可靠的密钥派生函数，如PBKDF2。
CryptoJS 支持这些变体，但 cCryptoGS 显然不支持，至少包装的功能不支持。

还请注意，至少链接的 cCryptoGS 源似乎基于 2013 年的 CryptoJS 版本 3.1.2，s。 cCryptoGS sources（当前 CryptoJS 版本为 4.1.1）。