OpenSSL vs GPG 用于加密异地备份？ [关闭]

Question

考虑到在将存档推送到异地备份位置之前使用 GPG 和 OpenSSL 进行本地加密之间的选择，每种解决方案的优缺点是什么？

背景： 我目前管理一个基于 Ubuntu 14.04.1 的服务器基础架构，并在所有补丁可用时应用它们。

所有这些系统都是无头的，使用经过审查的预种子和自动化工具自动构建，并通过基于 Intel 的统一硬件上的 KVM 在虚拟机中运行。

我们偏爱 Ruby，但更偏爱“正确地做事”。由于这两个原因，我们选择了“备份” gem 作为创建我们想要保留的数据的加密存档的方法，因为它会为使用 Vagrant 的开发人员创建与生产中相同的加密存档，而不管机制如何它被传输。

所有软件和配置都通过 Puppet 进行管理，因此任何决定都不会影响“用户体验”或便利性。任一选项都将创建相关脚本来管理、验证或从创建的任何备份中恢复。

鉴于此，当用于此目的时，任一加密选项相对于另一选项是否具有任何优势？

Answer 1

我会选择 GPG 进行文件加密，它经过数十年的安全测试加密，并且很容易拥有多个“收件人”（备份密钥？）或带有公钥甚至服务器的签名（如果它们有用的话） .

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

OpenSSL 应该能够做所有相同的事情，（它自 1998 年就已经存在，但如果版本号意味着什么，它在 2010 年达到了版本 1）但很容易犯错误可能会大大降低安全性。从this post on security.stackexchange.com（从 2013 年 1 月开始）and another 由 159K 信誉用户，openssl enc 命令可能会留下一些不足之处：

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

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

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

密码和盐变成密钥和IV的过程没有记录，但是查看源代码显示它调用了OpenSSL特定的EVP_BytesToKey()函数，该函数使用自定义key derivation function与一些重复的哈希。这是一个非标准且未经严格审查的构造（！），它依赖于可疑声誉的 MD5 哈希函数（！！）；可以使用 undocumented -md 标志 (!!!) 在命令行上更改该功能； “迭代计数”由 enc 命令设置为 1 并且不能更改 (!!!!)。这意味着密钥的前 16 个字节将等于 MD5(password||salt)，仅此而已。

这很弱！任何知道如何在 PC 上编写代码的人都可以尝试破解这样的方案，并且能够每秒“尝试”数千万个潜在密码（使用 GPU 可以实现数亿美元）。 如果您使用“openssl enc”，请确保您的密码具有非常高的熵！（即高于通常推荐的值；目标至少为 80 位）。或者，最好根本不使用它；取而代之的是更健壮的东西（GnuPG，在对密码进行对称加密时，使用更强大的 KDF 和底层哈希函数的多次迭代）。

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

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