Openssl RC4 vs C++ RC4（加盐）答案

【问题标题】：Openssl RC4 vs C++ RC4 (with salt)Openssl RC4 vs C++ RC4（加盐）
【发布时间】：2019-04-15 17:09:43
【问题描述】：

我正在使用 RC4 C++ 程序进行更多工作，以与命令行参数兼容。我想知道是否有人可以指出一些关于命令行 openssl rc4 在加密和解密时如何使用盐的体面文档的方向，这样我就可以在我的程序中加入一些兼容性。感谢几天前这里有人的帮助，一旦合并了 EVP_bytestokey 函数，我的程序就与非盐版本兼容。我查看了 openssl 使用的 EVP_bytestokey 函数，文档显示它可以采用 salt 参数：

“salt参数在推导中用作salt：它应该指向一个8字节的缓冲区，如果没有使用salt，它应该指向NULL。”

我用 CLI 给我的 salt 创建了一个 unsigned char 数组，并将它们作为 ASCII 等价物存储在数组中，以作为 SALT 参数传入（到 EVP_bytestokey）。然后我比较了文件大小，它显示文件的加密/加盐版本比原始文件大 16 个字节。似乎 CLI 版本在文件中添加了“salted__”，但这仅占 16 个字节中的 8 个。有谁知道额外的 8 个字节来自哪里？据我了解，在传递到 RC4_setkey 的密钥流生成器之前，盐会预先添加到密码短语中，所以我不明白为什么要在“salted__”之外更改文件大小。

另外，你认为我使用 SALT 数组的方向正确吗，将十六进制值存储为 ASCII 等价物？

我有这里使用的 C 函数的文档，但我似乎找不到任何关于 CLI 版本机制的具体信息，所以如果我能在这里获得任何帮助，我将不胜感激。

【问题讨论】：

额外的 8 个字节可能是盐值，根据 enc(1)（尽管没有提到任何 salted__ 前缀）：当使用盐时，前八个字节加密数据的一部分保留给 salt：加密文件时随机生成，解密时从加密文件中读取。
RC4 有许多已知漏洞，并且在大多数用例中已被弃用。请不要在任何新代码中使用它。在旧代码中，请尝试摆脱/替换它。
是的，我终于在几分钟前的一个随机页面上发现了它。额外的 16 个字节是“salted___”（8 个字节），后跟盐的实际 8 个字节，作为 unsigned char 值。现在我正在努力在我的程序中获取盐的格式。我让用户从 openssl 输入盐作为两位十六进制值（其中 8 个），在输入上使用 std::hex 将其存储到 int 变量中。从那里，我会将它们全部转换为数组中的无符号整数，然后将其传递到盐中。
我让这个过程工作并在一个小测试 sn-p 上将正确的值输出到终端，所以希望它与我的实际程序有很好的相关性。一旦我确认可行，我将剪断加盐文件的前 16 个字节，然后将其传递给程序。如果我成功了，今天晚些时候会在这里更新。
是的，Jesper，我知道这些漏洞，并且 RC4 已在很大程度上被淘汰。这不适用于任何严肃的实施。这只是我正在研究的一个项目，以了解它是如何工作的。完成后，我将我的程序集成到我安装到本地机器上的 S3FS 实例中。不会被除我以外的任何人使用。

标签： c++ openssl salt rc4-cipher

【解决方案1】：

所以对于任何好奇的人，我想通了。带有 salt 选项的 OpenSSL RC4 会在加密后在文件开头添加 16 个字节。前 8 个字节是：“salted__”，后 8 个字节是实际的盐，显示为无符号字符。 Lseek 可用于跳过字节 1-8，然后字节 9-16 可以加载到无符号字符数组中（大小必须为 8 个字节）。然后，该数组应转换为 (const unsigned char*)，同时作为盐传递给 EVP_bytestokey()，这是第三个参数。

至于盐的用户输入选项，我将其设置为将两位十六进制输入输入到一个 int 变量中，然后我将其传递到 unsigned char salt 数组中。

【讨论】：