Почему Git не использует более современные SHA?

Я читал о том, что Git использует дайджест SHA-1 в качестве идентификатора для ревизии. Почему он не использует более современную версию SHA?

Источник

4 ответа

Решение

ОБНОВЛЕНИЕ: Приведенный выше вопрос и этот ответ относятся к 2015 году. С тех пор Google объявил о первом столкновении SHA-1: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Очевидно, я могу только строить догадки о том, почему Git продолжает использовать SHA-1, но это может быть одна из причин:

  1. Git был созданием Линуса Торвальда, и Линус, по-видимому, не хочет заменять SHA-1 другим алгоритмом хеширования.
  2. Он делает правдоподобные заявления о том, что успешные атаки на Git, основанные на столкновениях SHA-1, намного сложнее, чем достижение самих столкновений, и, учитывая, что SHA-1 слабее, чем должен быть, не полностью сломлен, что делает его существенно далеким от осуществимая атака по крайней мере сегодня. Кроме того, он отмечает, что "успешная" атака принесет очень мало, если сталкивающийся объект прибудет позже, чем существующий, так как последний будет считаться таким же, как действительный, и игнорироваться (хотя другие указали, что может произойти обратное).
  3. Смена программного обеспечения отнимает много времени и подвержена ошибкам, особенно когда существует существующая инфраструктура и данные, основанные на существующих протоколах, которые необходимо будет перенести. Даже те, кто производит программные и аппаратные продукты, где криптографическая безопасность является единственной точкой системы, все еще находятся в процессе перехода от SHA-1 и других слабых алгоритмов на местах. Просто представьте, что все эти закодированные unsigned char[20] повсеместно буферизирует;-), гораздо проще запрограммировать криптографическую гибкость при запуске, чем модифицировать ее позже.
  4. Производительность SHA-1 лучше, чем у различных хэшей SHA-2 (возможно, не так сильно, как сейчас, но может быть препятствием 10 лет назад), а объем хранилища SHA-2 больше,

Некоторые ссылки:

По моему личному мнению, в то время как практические атаки, вероятно, имеют некоторый перерыв, и даже когда они происходят, люди, вероятно, первоначально будут противодействовать им другими способами, помимо изменения самого алгоритма хеширования, что если вы действительно заботитесь о безопасности, вы должны ошибаться. будьте осторожны с вашим выбором алгоритмов и постоянно пересматривайте свои сильные стороны безопасности в сторону повышения, потому что возможности злоумышленников также движутся только в одном направлении, поэтому было бы неразумно брать Git в качестве образца для подражания, особенно в качестве его цели в использование SHA-1 не претендует на криптографическую безопасность.

Источник

Почему он не использует более современную версию SHA?

Декабрь 2017: будет. И Git 2.16 (Q1 2018) является первым выпуском, иллюстрирующим и реализующим это намерение.

Примечание: см. Git 2.19 ниже: это будет SHA-256.

В Git 2.16 будет предложена инфраструктура для определения того, какая хеш-функция используется в Git, и начнётся попытка внедрить ее в различные пути кода.

См. Коммит c250e02 (28 ноября 2017 г.) Рамси Джонсом (``).
См. Коммит eb0ccfd, коммит 78a6766, коммит f50e766, коммит abade65 (12 ноября 2017 г.) от brian m. Карлсон ( bk2204 )
(Объединено Юнио С Хамано - gitster - в коммите 721cc43, 13 декабря 2017 г.)

Добавить структуру, представляющую алгоритм хеширования

Поскольку в будущем мы хотим поддерживать дополнительный алгоритм хеширования, добавьте структуру, которая представляет алгоритм хеширования, и все данные, которые должны сопровождать его.
Добавьте константу, чтобы упростить перечисление алгоритмов хеширования.
Реализовать функцию typedefs создать абстрактный API, который может использоваться любым алгоритмом хеширования, и оболочки для существующих функций SHA1, которые соответствуют этому API.

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

Не включайте запись в структуру алгоритма хеширования для нулевого идентификатора объекта.
Поскольку это значение - все нули, можно использовать любой подходящий по размеру ИД объекта со всеми нулями, и нет необходимости хранить данный идентификатор отдельно для каждого хэша.

Текущий план перехода хэш-функции предусматривает время, когда мы примем ввод от пользователя, который может быть в формате SHA-1 или в формате NewHash.
Поскольку мы не можем знать, что предоставил пользователь, добавьте константу, представляющую неизвестный алгоритм, чтобы позволить нам указать, что мы должны искать правильное значение.

Интегрируйте поддержку алгоритма хеширования с настройкой репо

В будущих версиях Git мы планируем поддерживать дополнительный алгоритм хеширования.
Интегрируйте перечисление алгоритмов хеширования с настройкой хранилища и сохраните указатель на перечисленные данные в хранилище структур.
Конечно, в настоящее время мы поддерживаем только SHA-1, поэтому жестко запрограммируйте это значение в read_repository_format,
В будущем мы перечислим это значение из конфигурации.

Добавить константу, the_hash_algo, который указывает на hash_algo указатель структуры в репозитории глобальный.
Обратите внимание, что это хеш, который используется для сериализации данных на диск, а не хеш, который используется для отображения элементов пользователю.
План перехода предполагает, что они могут отличаться.
Мы можем добавить дополнительный элемент в будущем (скажем, ui_hash_algo) для этого случая.

Обновление от августа 2018 года для Git 2.19 (3-й квартал 2018 года). Git, похоже, выбрал SHA-256 как NewHash.

Смотрите коммит 0ed8d8d (04 августа 2018) Джонатана Нидера ( artagnon )
См. Коммит 13f5e09 (25 июля 2018 г.) от Ævar Arnfjörð Bjarmason ( avar )
(Объединено Юнио С Хамано - gitster - в комитете 34f2297 от 20 августа 2018 года)

доктор hash-function-transition: выберите SHA-256 как NewHash

С точки зрения безопасности, кажется, что SHA-256, BLAKE2, SHA3-256, K12 и т. Д., Как полагают, имеют схожие свойства безопасности.
Все это хорошие варианты с точки зрения безопасности.

SHA-256 имеет ряд преимуществ:

  • Он существует уже некоторое время, широко используется и поддерживается практически каждой криптографической библиотекой (OpenSSL, mbedTLS, CryptoNG, SecureTransport и т. Д.).

  • При сравнении с SHA1DC большинство векторизованных реализаций SHA-256 действительно быстрее, даже без ускорения.

  • Если мы делаем подписи с OpenPGP (или даже, я полагаю, CMS), мы будем использовать SHA-2, поэтому не имеет смысла, чтобы наша безопасность зависела от двух отдельных алгоритмов, когда любой из них один может сломать безопасность, когда мы можем просто зависеть от одного.

Так что SHA-256 это так.
Обновите документ конструктора hash-function-transition, чтобы так сказать.

После этого патча нет оставшихся экземпляров строки " NewHash ", за исключением несвязанного использования с 2008 года в качестве имени переменной в t/t9700/test.pl,

Вы можете увидеть этот переход к SHA 256 в процессе выполнения с Git 2.20 (Q4 2018):

См. Коммит 0d7c419, коммит dda6346, коммит eccb5a5, коммит 93eb00f, коммит d8a3a69, коммит fbd0e37, коммит f690b6b, коммит 49d1660, коммит 268babd, коммит fa13080, коммит 7b5e614, коммит 58ce21b, коммит 2f0c25a9e9, 99 , Карлсон ( bk2204 )
См. Коммит 6afedba (15 октября 2018 г.) SZEDER Gábor ( szeder )
(Объединено Юнио С Хамано - gitster - в комитете d829d49 от 30 октября 2018 года)

заменить жестко закодированные константы

Заменить несколько основанных на 40 констант ссылками на GIT_MAX_HEXSZ или же the_hash_algo в зависимости от обстоятельств.
Конвертировать все виды использования GIT_SHA1_HEXSZ использовать the_hash_algo так что они подходят для любой длины хеша.
Вместо использования жестко запрограммированной константы для размера шестнадцатеричного идентификатора объекта, переключитесь на использование вычисленного указателя из parse_oid_hex это указывает после проанализированного идентификатора объекта.

Источник

Здесь обсуждается срочность перехода с SHA1 для Mercurial, но это касается и Git: https://www.mercurial-scm.org/wiki/mpm/SHA1

Короче говоря: если вы не слишком усердны сегодня, у вас гораздо худшие уязвимости, чем у sha1. Но, несмотря на это, Mercurial начал более 10 лет назад, чтобы подготовиться к переходу от Sha1.

В течение многих лет велась работа по модернизации структур данных и протоколов Mercurial для преемников SHA1. Место хранения было выделено для больших хэшей в нашей структуре revlog более 10 лет назад в Mercurial 0.9 с введением RevlogNG. Формат bundle2, представленный совсем недавно, поддерживает обмен различными типами хэшей по сети. Единственными оставшимися частями являются выбор функции замены и выбор стратегии обратной совместимости.

Если git не мигрирует из sha1 раньше, чем Mercurial, вы всегда можете добавить другой уровень безопасности, сохраняя локальное зеркало Mercurial с помощью hg-git.

Источник

В настоящее время существует план перехода к более сильному хешу, поэтому в будущем он будет использовать более современный хеш, чем SHA-1. Из текущего плана перехода:

Рассматриваются некоторые хэши SHA-256, SHA-512/256, SHA-256x16, K12 и BLAKE2bp-256

Источник
Другие вопросы по тегам