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

OpenSSL vs GPG for encrypting off-site backups?

提问by K. Darien Freeheart

Given the option between using GPG and OpenSSL for local encryption before pushing archives to an off-site backup location, what are the benefits and drawbacks of each solution?

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

Background: I currently manage a server infrastructure based on Ubuntu 14.04.1 with all current patches applied as they become available.

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

All of these systems are headless, automatically built using vetted preseeds and automation tools, and run in virtual machines via KVM on uniform Intel-based hardware.

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

We have a preference for Ruby, but a stronger preference for "doing things correctly". Because of both, we've chosen the "backup" gem as the means to create encrypted archives of data we want preserved, since it will create the same encrypted archives for a developer using Vagrant that it would in production, regardless of the mechanism by which it's transmitted.

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

All software and configuration is managed via Puppet, so neither decision will have any impact on "user experience" or convenience. Either option will create relevant scripts to manage, verify, or restore from any backups created.

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

Given that, does either encryption option offer any advantage against the other when used for this purpose?

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

回答by Xen2050

I would pick GPG for file encryption, it's got decades of secure tested encryption, and is very easy to have multiple "recipients" (backup keys?) or signatures with it's public keys & even servers (if they would be useful).

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

With GPG, all the simple mistakes have been avoided/fixed, it picks a longer "random" key for the actual encryption and does a good number of "rounds" to make it very secure.

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

OpenSSL shouldbe able to do all the same things, (it's been around since 1998, but if version numbers mean anything it reached version 1 in 2010) but it's very easy to make a mistake that could drastically lower the security. And from this post on security.stackexchange.com(from Jan 2013) and anotherby a 159K reputation user, the openssl enccommand might leave something to be desired:

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

The encryption format used by OpenSSL is non-standard: it is "what OpenSSL does", and if all versions of OpenSSL tend to agree with each other, there is still no reference document which describes this format except OpenSSL source code. The header format is rather simple:

magic value (8 bytes): the bytes 53 61 6c 74 65 64 5f 5f salt value (8 bytes)

Hence a fixed 16-byte header, beginning with the ASCII encoding of the string "Salted__", followed by the salt itself. That's all ! No indication of the encryption algorithm; you are supposed to keep track of that yourself.

The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey()function, which uses a custom key derivation functionwith some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented-mdflag (!!!); the "iteration count" is set by the enccommand to 1and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it.

This is quite weak !Anybody who knows how to write code on a PC can try to crack such a scheme and will be able to "try" several dozens of millions of potential passwords per second (hundreds of millions will be achievable with a GPU). If you use "openssl enc", make sure your password has very high entropy !(i.e. higher than usually recommended; aim for 80 bits, at least). Or, preferably, don't use it at all; instead, go for something more robust (GnuPG, when doing symmetric encryption for a password, uses a stronger KDF with many iterations of the underlying hash function).

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(password||salt)，就是这样。

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

man enceven has this under "BUGS":

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

There should be an option to allow an iteration count to be included.

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