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

Question

想要改进这个问题吗？更新问题，以便通过编辑这篇文章用事实和引用来回答。

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

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

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

我们偏爱 Ruby，但更偏爱“正确做事”。由于两者兼而有之，我们选择了“备份”gem作为创建我们想要保留的数据的加密档案的方法，因为它将为使用Vagrant的开发人员创建与生产中相同的加密档案，无论它通过何种机制传输。

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

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

Answer 1

我会选择GPG进行文件加密，它有数十年的安全测试加密，并且很容易拥有多个“收件人”（备份密钥？）或带有公钥的签名

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

OpenSSL应该能够做所有相同的事情（它从1998年就开始了，但如果版本号意味着什么，它在2010年达到了版本1），但很容易犯错误，这可能会大大降低安全性。这篇关于security.stackeexchange的文章。com（从2013年1月开始）和另一个159K信誉用户的openssl-enc命令可能会留下一些不需要的东西：

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

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

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

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

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

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

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