OpenSSL против GPG для шифрования резервных копий за пределами площадки?

Учитывая возможность использования GPG и OpenSSL для локального шифрования, прежде чем нажимать архивы на место резервного копирования за пределами площадки, каковы преимущества и недостатки каждого решения?

Фон: В настоящее время я управляю инфраструктурой сервера на основе Ubuntu 14.04.1 со всеми текущими исправлениями, применяемыми по мере их появления.

Все эти системы являются безголовыми, автоматически создаются с использованием проверенных предварительных запросов и средств автоматизации и запускаются на виртуальных машинах через KVM на унифицированном оборудовании на базе Intel.

Мы предпочитаем Ruby, но более сильное предпочтение "правильно делать вещи". Из-за этого мы выбрали "резервный" драгоценный камень в качестве средства для создания зашифрованных архивов данных, которые мы хотим сохранить, поскольку он будет создавать те же зашифрованные архивы для разработчика, используя Vagrant, которые он будет производить, независимо от механизма который он передал.

Все программное обеспечение и конфигурация управляются через Puppet, поэтому ни одно решение не будет влиять на "пользовательский опыт" или удобство. Любой из этих параметров создает соответствующие сценарии для управления, проверки или восстановления из созданных резервных копий.

Учитывая, что любая опция шифрования дает преимущество перед другим при использовании для этой цели?

Ответ 1

Я бы выбрал GPG для шифрования файлов, он получил десятилетия безопасного тестирования шифрования и очень легко иметь несколько "получателей" (резервные ключи?) или подписи с него открытыми ключами и даже серверами (если они будут полезны).

С GPG все простые ошибки были устранены/исправлены, он выбирает более длинный "случайный" ключ для фактического шифрования и делает большое количество "раундов", чтобы сделать его очень безопасным.

OpenSSL должен иметь возможность делать все то же самое (он существует с 1998 года, но если номера версий означают, что он достиг 1-й версии в 2010 году), но очень легко сделать ошибку, которая может значительно снизить безопасность. И от этого сообщения на security.stackexchange.com (с января 2013 года) и еще от пользователя репутации 159K, команда openssl enc может оставить желать лучшего:

Формат шифрования, используемый OpenSSL, нестандартен: это "то, что делает OpenSSL", и если все версии OpenSSL имеют тенденцию согласовываться друг с другом, до сих пор нет справочного документа, который описывает этот формат, кроме исходного кода OpenSSL. Формат заголовка довольно прост:

магическое значение (8 байт): байты 53 61 6c 74 65 64 5f 5f значение соли (8 байтов)

Следовательно, фиксированный 16-байтовый заголовок, начинающийся с кодировки ASCII строки "Salted__", за которой следует сама соль. Все это! Отсутствует указание алгоритма шифрования; вы должны сами следить за этим.

Процесс, с помощью которого пароль и соль превращаются в ключ, и IV не документируется, но просмотр исходного кода показывает, что он вызывает OpenSSL-специфический EVP_BytesToKey(), которая использует пользовательскую encна 1 и не может быть изменен (!!!!). Это означает, что первые 16 байтов ключа будут равны MD5 (пароль || соль) и что он.

Это довольно слабо! Любой, кто знает, как писать код на ПК, может попытаться взломать такую схему и сможет" попробовать "несколько десятков миллионов потенциальных паролей в секунду ( сотни миллионов будут достигнуты с помощью графического процессора). Если вы используете" openssl enc ", убедитесь, что ваш пароль имеет очень высокую энтропию! (т.е. выше, чем обычно рекомендуется, по крайней мере, для 80 бит). Или, предпочтительно, не используйте его вообще; вместо этого переходите к чему-то более надежному ( GnuPG, при выполнении симметричного шифрования для пароля используется более сильный KDF со многими итерациями основного хэша функция).

man enc даже имеет это под "ОШИБКИ":

Должна быть опция, позволяющая включить подсчет итераций.