OpenSSL 与 GPG 加密异地备份？

我会选择 GPG 文件加密，它有几十年的安全测试加密，并且很容易有多个“收件人”(备份密钥?)或使用其公钥甚至服务器的签名(如果它们有用的话)。

在 GPG 中，所有简单的错误都被避免/修复了，它为实际的加密选择了一个更长的“随机”密钥，并进行了大量的“循环”以使其非常安全。

OpenSSL 应该可以做所有相同的事情，(它从1998年开始使用，但是如果版本号有任何意义的话，它在2010年就达到了版本1)但是很容易出错，这会大大降低安全性。从 这篇关于 security.stackexchange.com 的文章(从2013年1月开始)到159K 声誉用户的 还有另一个，openssl enc命令可能会留下一些需要改进的地方:

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

Magic 值(8字节) : 字节53616c 7465645f 5f Salt 值(8字节)

因此，一个固定的16字节的头部，从字符串“ Salted _ _”的 ASCII 编码开始，然后是 salt 本身。仅此而已！没有加密算法的迹象，你应该自己保持跟踪。

将密码和 salt 转换为密钥和 IV 的过程没有文档说明，但是查看源代码可以看出，它调用了 OpenSSL 特定的 EVP _ BytesToKey ()函数，该函数使用一个定制的 密钥导出函数并进行一些重复散列。这是一个非标准的、经过严格审查的构造(!)它依赖于声誉可疑的 MD5散列函数(! !); 该函数可以在命令行上用 非法移民 -md标志更改(! !); “迭代计数”由 enc命令设置为 1，不能更改(! ! !).这意味着密钥的前16个字节等于 MD5(密码 | | salt)，就是这样。

这太弱了！任何知道如何在 PC 上编写代码的人都可以尝试破解这种方案，并且每秒钟可以“尝试”数千万个潜在的密码(使用 GPU 可以实现数亿个密码)。如果您使用“ openssl enc”，请确保您的密码具有非常高的熵！(即高于通常的推荐值; 目标至少为80位)。或者，最好根本不使用它; 相反，使用更健壮的东西(GnuPG在对密码进行对称加密时，使用更强大的 KDF，并对底层散列函数进行多次迭代)。