Является ли Openssl Aes-Encryption потерянным?

Question

Как использовать шифрование в командной строке, могу ли я использовать это как надежный способ резервного копирования?

Я на Os X, кстати.

Что я пробовал:

zip -er ./test.zip ./test # zip w/ password

Добавил это в мой .bash_profile

#$1 == input file
#$2 == output file
aesenc ()
{
        openssl enc -aes-256-cbc -salt -in "$1" -out "$2"
}

#$1 == enc file
#$2 == out file
aesdecr ()
{
        openssl enc -d -aes-256-cbc -in "$1" -out "$2"
}

aesenc test.zip test.zip.enc aesdecr test.zip.enc test.zip

Я проверил файлы, и все выглядит хорошо на поверхности.

Просто хотел узнать, знает ли кто-нибудь больше?

Answer 1

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

Команда enc в Openssl не "с потерями", поэтому она должна быть надежной для данных ... но IMO, использующая программу с более длинной историей и лучшей обработкой ключей, такую как gpg/pgp, была бы лучше для безопасных зашифрованных резервных копий. Он рекомендован г-ном Эдвардом Сноуденом и является относительно "правительственным доказательством", и, по крайней мере, в прошлом я читал кое-что о коде openssl, которое касается.

См. Этот вопрос OpenSSL против GPG для шифрования резервных копий вне сайта? для получения дополнительной информации, например:

из этого поста на 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 даже имеет это под "BUGS":

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