Плохая криптографическая практика в Git-encrypt?

Комментарии к состоянию https://gist.github.com/shadowhand/873637

«Шифрование в режиме ECB — это относительно простой метод шифрования, который обеспечивает высокий уровень запутывания (или низкий уровень шифрования). Этот метод не очень безопасен и не должен использоваться для конфиденциальных личных данных, но будет хорошо работать, например, для. передача исходного кода между частными сторонами по общедоступному каналу. Для большей безопасности вы можете переключить режим на CBC за счет полного изменения каждого файла для каждой модификации. Как и при любом шифровании, всегда рекомендуется надежный ключ».

и

«Это своего рода (часть) определения функционально правильного шифрования — ECB (нажмите здесь для объяснения) — это ошибочная устаревшая реализация, никем не рекомендованная для текущего использования сегодня и поддерживаемая только в OpenSSL, потому что OpenSSL поддерживает некоторые очень старые и скрипучие устаревшие криптографические реализации! Это полезно только сегодня как инструмент обучения и никогда не должно использоваться в текущих системах.

Режимы CBC или OFB должны использоваться по умолчанию — пожалуйста, подумайте об изменении сути, чтобы использовать CBC, и объясните потенциальные преимущества ECB наряду с недостатками для тех, кто хотел бы смириться с потерей безопасности ради небольшого удобства в git. Ничто не должно быть небезопасным по умолчанию!»

http://git.661346.n2.nabble.com/Transparently-encrypt-repository-contents-with-GPG-td2470145.html однако утверждает, что использование соли с фиксированным значением для CBC является плохой криптографической практикой. Если бы мы переключили режим на CBC (для https://gist.github.com/shadowhand/873637 или https://github.com/shadowhand/git-encrypt), будет ли он использовать соль с фиксированной стоимостью и, следовательно, плохая криптопрактика?

(Я также разместил этот вопрос в качестве комментария на https://gist.github.com/shadowhand/873637. )


person Daniel    schedule 08.07.2015    source источник


Ответы (1)


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

ECB небезопасен, если один и тот же блок может быть зашифрован несколько раз. Например, длинные отрывки естественного языка могут содержать повторяющиеся подстроки. Или несколько сообщений данного протокола, вероятно, будут иметь один и тот же префикс или суффикс. Использование ECB с таким открытым текстом выявит шаблоны в открытом тексте.

Термин «соль с фиксированной стоимостью для CBC» не имеет никакого смысла. «Соль» используется при создании секретного ключа из пароля. CBC требует «вектора инициализации», который должен быть непредсказуемым для каждого зашифрованного сообщения. (Некоторые взломанные криптографические протоколы в прошлом генерировали IV и ключи из пароля; это безопасно, только если пароль используется для шифрования только одного сообщения.) В идеале IV генерируется криптографическим генератором случайных битов; использование фиксированного IV в режиме CBC может выявить шаблоны в префиксах сообщений, как и ECB.

Чтобы узнать, безопасен ли здесь ЕЦБ, потребуется больше контекста (вопросы должны быть автономными и не содержать ненужной информации). Однако общее заявление о том, что ЕЦБ всегда небезопасен, неверно; он может быть безопасным в правильном приложении, а его более короткие зашифрованные тексты иногда могут быть ценными.

person erickson    schedule 08.07.2015
comment
Спасибо. В этом контексте я думаю, что ECB используется для шифрования базы кода. (Он используется в следующей строке: openssl enc -d -base64 -aes-256-ecb ...). Я думаю, что (как и в случае с длинными фрагментами естественного языка) кодовая база также может содержать повторяющиеся подстроки, и, следовательно, использование ECB здесь небезопасно. Имеет ли это смысл? - person Daniel; 08.07.2015
comment
Только что заметил, что на github.com/shadowhand/git-encrypt упоминается, что необходимо использовать статическую соль (и, следовательно, использование CBC обеспечит очень небольшое повышение безопасности по сравнению с режимом ECB). Я предполагаю, что статическая соль означает то же самое, что и соль с фиксированным значением, но я не уверен в этом. Согласно stackoverflow.com/a/5935372/805141... не существует такого понятия, как "статическая соль". Если не случайно, то это не соль, а ключ. - person Daniel; 08.07.2015
comment
Да, шифрование исходного кода с помощью ECB небезопасно. Шифрование разных исходных кодов с помощью CBC с использованием одного и того же IV также было бы небезопасным. - person erickson; 08.07.2015
comment
@Daniel Я нашел время, чтобы прочитать все комментарии на github. Я не очень понимаю применение здесь. Нужно ли использовать эти фильтры, чтобы репо, синхронизируемое через Dropbox, было зашифровано? Если это идея, я бы предложил использовать Wuala вместо Dropbox. Похоже, что с этой сутью будет зашифровано только само содержимое файла, а не какие-либо метаданные, и, вероятно, в метаданных содержится много информации о данных. Все репо должно быть зашифровано с помощью шифрующей файловой системы. - person erickson; 09.07.2015
comment
Спасибо за это. У меня сложилось впечатление, что это решение предназначено для использования с любой службой, а не только с Dropbox. Хотя это хороший момент. В любом случае, я подумываю перейти на github.com/bluss/git-remote-gcrypt, так как я пока не обнаружил никаких проблем с безопасностью. - person Daniel; 10.07.2015