OpenSSL vs GPG用于加密异地备份？

作者: 狗头军师
发布时间: 2024-12-19 07:35:45 (2月前)

2 条回复

1#
回复此人
v-star*위위 | 2020-08-20 14-16

我会选择GPG进行文件加密，它经过数十年的安全测试，并且很容易拥有多个“收件人”（备份密钥？）或带有公钥甚至服务器的签名（如果有用）。使用GPG，可以避免/解决所有简单的错误，它为实际的加密选择了更长的“随机”密钥，并进行了大量的“回合”以使其非常安全。 OpenSSL 应该能够做所有相同的事情（自1998年以来一直存在，但是如果版本号意味着它可以在2010年达到版本1），那么很容易犯一个会大大降低安全性的错误。从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编码开始，然后是salt本身。就这样！没有指示加密算法；您应该自己跟踪自己。密码和盐变成密钥和IV的过程没有记录，但是查看源代码表明它调用了OpenSSL特定的EVP_BytesToKey（）函数，该函数使用具有一些重复哈希的自定义密钥派生函数。这是一个非标准且未经严格审查的构造（！），它依赖于可疑信誉（!!）的MD5哈希函数；可以在命令行上使用未记录的 -md标志（!!!）更改该功能；该enc命令将“迭代次数”设置为1，并且无法更改（!!!!）。这意味着密钥的前16个字节将等于MD5（password || salt），仅此而已。这是相当薄弱的！任何知道如何在PC上编写代码的人都可以尝试破解这种方案，并且每秒可以“尝试”数千万个潜在的密码（使用GPU可以实现数亿个）。如果您使用“ openssl enc”，请确保您的密码具有很高的熵！（即高于通常建议的值；至少要达到80位）。或者，最好根本不使用它；取而代之的是，使用更健壮的东西（GnuPG，在对密码进行对称加密时，使用更强大的KDF以及底层哈希函数的许多迭代）。 man enc 甚至在“错误”下有此内容：应该有一个选项允许包含迭代计数。

编辑

登录后才能参与评论