OpenSSL vs GPG用于加密异地备份？ [英] OpenSSL vs GPG for encrypting off-site backups?

问题描述

考虑到将GPG和OpenSSL用于本地加密之前的选项，请将存档推送到异地备份位置之前，每个解决方案的优点和缺点是什么？

背景：
我目前管理基于Ubuntu 14.04.1的服务器基础架构，所有当前的补丁都可以应用于其中。

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

我们偏爱Ruby，但更偏爱做事正确。因为这两者，我们选择了备份宝石作为创建我们要保存的数据的加密存档的手段，因为它将为使用生产中的Vagrant的开发人员创建相同的加密存档，而不管机制如何它被传输。

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

鉴于此，加密选项在为此目的使用时可以提供任何优势？

解决方案

我会选择GPG进行文件加密，它有几十年的安全测试加密，并且很容易拥有多个收件人（备份密钥）或签名，其公钥和甚至服务器（如果它们将是有用的）。

使用GPG，所有简单的错误都已被避免/修复，它为实际加密选择了更长的随机密钥并且做了很多轮，使其非常安全。

OpenSSL 应该能够做所有相同的事情（它是自1998年以来一直存在，但如果版本号意味着任何它在2010年达到版本1），但是很容易犯错误，可能会大大降低安全性。而且从这篇post on security.stackexchange.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（）函数，该函数使用自定义密钥导出功能，并重复散列。这是一个非标准而不是很好的vetted构造（！），它依赖于可疑信誉的MD5哈希函数（!!）;该功能可以在命令行中使用未记录的 -md 标志（!!!）更改; 迭代计数由 enc 命令设置为 1 ，不能更改（!!!!）。这意味着密钥的前16个字节将等于MD5（密码|| salt），就是这样。

这是非常弱的！任何知道如何在PC上编写代码的人都可以尝试破解这样一个方案，并且能够尝试每秒几十万个潜在的密码（数亿个用GPU实现）。 如果您使用openssl enc，请确保您的密码具有非常高的熵！（即高于通常推荐的值;至少为80位）。或者，最好不要使用它;而是，为了更加强大的一些功能（ GnuPG ，当对密码进行对称加密时，使用更强大的KDF与许多底层哈希函数的迭代）。

man enc 甚至有BUGS：

应该有一个选项可以包含迭代计数。

< blockquote>

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?

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

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.

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.

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.

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

解决方案

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).

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.

OpenSSL should be 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 another by a 159K reputation user, the openssl enc command might leave something to be desired:

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 function with 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 -md flag (!!!); the "iteration count" is set by the enc command to 1 and 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).

man enc even has this under "BUGS":

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

这篇关于OpenSSL vs GPG用于加密异地备份？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！