☰

Openssl Aes 加密有损吗？

tag-icon • tag-icon macos encryption zip openssl
Openssl Aes 加密有损吗？

按照如何命令行 aes-encrypt，我可以用它作为可靠的备份方式吗？

顺便说一下，我在使用 Os X。

我尝试过的：

zip -er ./test.zip ./test # zip w/ password

已将此添加到我的.bash_profile

#$1 == input file
#$2 == output file
aesenc ()
{
        openssl enc -aes-256-cbc -salt -in "$1" -out "$2"
}

#$1 == enc file
#$2 == out file
aesdecr ()
{
        openssl enc -d -aes-256-cbc -in "$1" -out "$2"
}

aesenc test.zip test.zip.enc aesdecr test.zip.enc test.zip

我检查了文件，表面上一切似乎都正常。

只是想听听是否有人知道更多信息？

答案1

我想你的意思是有损压缩就像 jpeg 一样，有损压缩会不可逆转地丢失数据，有损压缩对于通常的数据来说会很糟糕，并且只适用于图像，因为即使丢失数据后图像仍然看起来“足够好”。

Openssl 的 enc 命令不是“有损的”，因此它应该数据可靠...但在我看来，使用具有更长历史和更好的密钥处理能力的程序，例如gpg/pgp，更适合安全加密备份。这是爱德华·斯诺登先生推荐的，相对来说“政府认证”，至少在过去我读过一些关于 openssl 的 enc 令人担忧的内容。

请参阅此问题OpenSSL 与 GPG 用于加密异地备份吗？了解更多信息，例如：

从security.stackexchange.com 上的这篇文章（自 2013 年 1 月起）和另一个对于 159K 信誉用户来说，该openssl enc命令可能会有些不尽如人意：

OpenSSL 使用的加密格式是非标准的：它是“OpenSSL 所做的”，如果所有版本的 OpenSSL 都倾向于彼此一致，那么除了 OpenSSL 源代码之外，仍然没有参考文档描述这种格式。标头格式相当简单：

魔法值（8字节）：字节 53 61 6c 74 65 64 5f 5f 盐值（8字节）

因此，固定的 16 字节标头以字符串“Salted__”的 ASCII 编码开头，后面跟着盐本身。就这些！没有加密算法的指示；您应该自己跟踪它。

密码和盐转换成密钥和 IV 的过程没有记录，但查看源代码可以发现它调用 OpenSSL 特定的EVP_BytesToKey()函数，它使用自定义密钥导出函数经过一些重复的哈希处理。这是一个非标准且未经充分审查的构造（！），它依赖于声誉可疑的 MD5 哈希函数（！！）；该函数可以在命令行上使用以下命令进行更改未记录的 -md标志（!!!）；“迭代计数”由命令设置enc为1并且无法更改（！！！！）。这意味着密钥的前 16 个字节将等于MD5(密码||盐)，就这样。

这太弱了！任何知道如何在 PC 上编写代码的人都可以尝试破解这种方案，并且每秒可以“尝试”几千万个潜在密码（使用 GPU 可以实现数亿个）。如果您使用“openssl enc”，请确保您的密码具有非常高的熵！（即高于通常建议的；至少要达到 80 位）。或者，最好根本不使用它；而是选择更强大的东西（基努在对密码进行对称加密时，使用更强的 KDF 并对底层哈希函数进行多次迭代）。

man enc甚至在“BUGS”下也有这个：

应该有一个选项可以允许包含迭代计数。

相关内容