在将归档文件推送到异地备份位置之前，可以 Select 使用GPG和OpenSSL进行本地加密，每种解决方案的优缺点是什么？
背景:
所有这些系统都是无头的，使用经过审查的preseeds和自动化工具自动构建，并通过KVM在基于英特尔的统一硬件上运行在虚拟机中.
我们更喜欢Ruby，但更喜欢"正确做事".由于这两个原因，我们 Select 了"备份"gem作为创建我们想要保存的数据加密档案的手段，因为它将为使用Vagrant的开发人员创建与在生产中相同的加密档案，而不管传输机制如何.
所有软件和配置都是通过Puppet管理的，因此这两个决定都不会对"用户体验"或便利性产生任何影响.任一选项都将创建相关脚本，以管理、验证或从创建的任何备份中恢复.
鉴于此，当用于此目的时，两种加密选项中的任何一种都比另一种具有优势吗？
我会 Select GPG进行文件加密，它有几十年的安全测试加密，很容易有多个"收件人"(备份密钥？)或者用公钥签名&；甚至服务器(如果它们有用的话).
有了GPG，所有简单的错误都被避免/修复了，它为实际加密 Select 了一个更长的"随机"密钥，并进行了大量的"循环"，使其非常安全.
OpenSSL should可以做所有相同的事情(它从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
因此，有一个固定的16字节头，以字符串"Salted_u_;"的ASCII编码开始，然后是salt本身.这就是全部！没有显示加密算法；你应该自己记录下来.
密码和salt转换为密钥和IV的过程没有文档记录，但查看源代码可以发现它调用了OpenSSL特定的EVP_BytesToKey()函数，该函数使用了一个自定义key derivation function，并进行了一些重复的哈希运算.这是一个非标准且未经充分审查的构造(！)它依赖于信誉可疑的MD5哈希函数(！！)；可以在命令行上使用undocumented
-md标志(！！！)更改该功能；"迭代计数"由enc命令设置为1，不能更改(！！！！).这意味着密钥的前16个字节将等于MD5(password||salt)，就是这样.This is quite weak !任何知道如何在PC上编写代码的人都可以try 破解这种方案，并且每秒可以"try "数亿个潜在密码(使用GPU可以实现数亿个密码).If you use "openssl enc", make sure your password has very high entropy !位(即高于通常建议的值；目标至少为80位).或者，最好不要使用它；取而代之的是更健壮的方法(GnuPG，当对密码进行对称加密时，使用更强的KDF，并多次迭代底层的哈希函数).
man enc甚至在"BUGS"下有这样的内容:
应该有一个允许包含迭代计数的选项.