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

Question

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

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

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

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

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

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

Answer 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(), которая использует специальную функцию вывода ключа с некоторым повторным хэшированием., Это нестандартная и недостаточно проверенная конструкция (!), Которая использует хеш-функцию MD5 с сомнительной репутацией (!!); эта функция может быть изменена в командной строке с недокументированным -md флаг (!!!); "количество итераций" устанавливается enc команда на 1 и не может быть изменена (!!!!). Это означает, что первые 16 байтов ключа будут равны MD5(пароль || соль), и все.

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

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

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