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

Question

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

背景:我目前管理一个基于Ubuntu 14.04.1的服务器基础设施，所有当前的补丁在可用时都会应用。

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

我们更喜欢Ruby，但更倾向于“正确地做事情”。由于两者的原因，我们选择了“备份”gem作为创建我们想要保留的数据的加密归档的方法，因为它将为使用Vagrant的开发人员创建与在生产中相同的加密归档，而不管它是通过什么机制传输的。

所有的软件和配置都是通过Puppet管理的，所以这两个决定都不会对“用户体验”或便利性产生任何影响。任一选项都将创建相关脚本，以管理、验证或恢复创建的任何备份。

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

Answer 1

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

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

OpenSSL应该能够做所有相同的事情(它从1998年就出现了，但如果版本号有什么意义的话，它在2010年达到了版本1)，但它很容易犯错误，从而极大地降低安全性。而在159K信誉用户的this post on security.stackexchange.com (从2013年1月开始) and another中，openssl enc命令可能会留下一些需要的东西：

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

魔术值(8字节)：字节53 61 6c 74 65 64 5f 5f盐值(8字节)

因此，固定的16字节头，从字符串"Salted__“的ASCII码开始，然后是salt本身。这就是全部！没有加密算法的提示；你应该自己跟踪它。

密码和salt转换为密钥和IV的过程没有文档记录，但是查看源代码就会发现它调用了特定于OpenSSL的EVP_BytesToKey()函数，该函数使用带有一些重复散列的自定义key derivation function。这是一个非标准且未经过良好审查的构造(!)它依赖于信誉可疑的MD5散列函数(!!)；该函数可以在命令行上使用未记录的-md标志(！)进行更改；“迭代计数”由enc命令设置为1，不能更改(！)。这意味着密钥的前16个字节等于MD5(password||salt)，仅此而已。

这是相当弱的!任何知道如何在PC上编写代码的人都可以尝试破解这样的方案，并将能够每秒“尝试”数千万个潜在的密码(数亿个密码将可以用图形处理器实现)。如果您使用"openssl enc"，请确保您的密码具有非常高的熵! (即高于通常推荐的值，目标至少为80位)。或者，最好根本不使用它；取而代之的是，使用更健壮的方法(GnuPG在对密码进行对称加密时，使用更强的KDF，并对底层散列函数进行多次迭代)。

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

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