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


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

4   51   2015-01-27 00:28:07

4 ответа:

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


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

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

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

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

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

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

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

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

посмотреть commit c250e02 (28 ноября 2017) by Рамсей Джонс (`).
Смотрите commit eb0ccfd,совершить 78a6766,commit f50e766,commit abade65 (12 ноября 2017) by Брайан м. Карлсон (bk2204).
(слитый Junio C Hamano--gitster-- на commit 721cc43, 13 Дек 2017)


добавить структуру представление хэш-алгоритма

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

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

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

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


интеграция поддержки хэш-алгоритма с настройкой РЕПО

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

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


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

посмотреть commit 0ed8d8d (04 авг 2018) by Джонатан Нидер (artagnon).
Смотрите совершить 13f5e09 (25 июля 2018) by Ævar Arnfjörð Bjarmason (avar).
(слитый Junio C Hamano--gitster-- на commit 34f2297, 20 августа 2018)

doc 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, поэтому не имеет смысла, чтобы наша безопасность зависела от двух отдельных алгоритмов, когда либо один из них только они могут нарушить безопасность, когда мы можем просто положиться на одного.

так ша-256 это.
Обновите документ дизайна хэш-функции-перехода, чтобы сказать об этом.

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

Это обсуждение срочности перехода от 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, вы можете всегда добавляйте еще один уровень безопасности, сохраняя локальное ртутное зеркало с hg-git.

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

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