考虑到在将存档推送到场外备份位置之前使用GPG和OpenSSL进行本地加密之间的选择，每个解决方案的优点和缺点是什么？
背景： 我目前管理基于Ubuntu 14.04.1的服务器基础架构，当所有当前补丁可用时都会应用。
所有这些系统都是无头的，使用经过审查的预制种子和自动化工具自动构建，并通过统一的基于Intel的硬件上的KVM在虚拟机中运行。
我们偏爱Ruby，但更倾向于“正确地做事”。由于两者兼而有之，我们选择“备份”gem作为创建我们想要保留的数据的加密存档的手段，因为它将为使用Vagrant的开发人员创建相同的加密存档，无论其机制如何它传播了。
所有软件和配置都通过Puppet进行管理，因此这两项决定都不会对“用户体验”或便利性产生任何影响。这两个选项都将创建相关脚本，以便从创建的任何备份中进行管理，验证或还原。
鉴于此，当用于此目的时，任一加密选项是否对另一个提供任何优势？
答案 0 :(得分：63)
我会选择GPG进行文件加密，它需要数十年的安全测试加密，并且很容易拥有多个接收者＆＃34; （备份密钥？）或签名用它的公钥和＆amp;甚至服务器（如果它们有用）。
使用GPG，所有简单的错误都得到了避免/修复，它选择了更长的“随机”＃34;实际加密的关键，并进行了大量的＆＃34;轮次＆＃34;使其非常安全。
OpenSSL 应该能够做所有相同的事情，（它自1998年以来一直存在，但如果版本号意味着它在2010年达到版本1的任何东西），但它＆＃39;很容易犯错，可能会大大降低安全性。来自this post on security.stackexchange.com（2013年1月）{159}信誉用户openssl enc，-md命令可能会留下一些不足之处：
OpenSSL使用的加密格式是非标准的：它是＆＃34; OpenSSL做什么＆＃34;，如果所有版本的OpenSSL倾向于彼此一致，仍然没有描述此格式的参考文档除了OpenSSL源代码。标题格式相当简单：
魔术值（8字节）：字节53 61 6c 74 65 64 5f 5f 盐值（8字节）
因此是一个固定的16字节标题，从字符串＆＃34; Salted __＆＃34;的ASCII编码开始，然后是盐本身。这就是全部！没有加密算法的指示;你应该自己跟踪它。
密码和salt转换为密钥和IV的过程没有记录，但是查看源代码表明它调用特定于OpenSSL的and another函数，该函数使用自定义{{ 3}}有一些重复的散列。这是一个非标准且未经过良好审查的构造（！），它依赖于可疑声誉的MD5哈希函数（!!）;可以使用未记录的
enc标志（!!!）在命令行上更改该功能; ＆＃34;迭代计数＆＃34;由man enc命令设置为 1 ，无法更改（!!!!）。这意味着密钥的前16个字节将等于 MD5（密码|| salt），这就是它。这非常弱！任何知道如何在PC上编写代码的人都可以尝试破解这样的方案，并且能够“尝试”＃34;每秒几十万个潜在密码（使用GPU可以实现数亿个密码）。 如果您使用＆＃34; openssl enc＆＃34;，请确保您的密码具有非常高的熵！（即高于通常建议的值;至少为80位）。或者，最好不要使用它;相反，在为密码进行对称加密时，使用更强大的KDF和基础哈希函数的多次迭代，可以获得更强大的功能（EVP_BytesToKey()。）
{{1}}甚至在＆＃34; BUGS＆＃34;：
之下应该有一个选项允许包含迭代计数。