Почему Git использует криптографическую хэш-функцию?

Ответ 1

Вы можете проверить, что из сам Линус Торвальдс, когда он представил Git Google еще в 2007 году:
(акцент мой)

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

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

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

Таким образом, есть некоторые причины, как и криптографическая сторона, но это действительно о способности доверять вашим данным.
Я гарантирую, что если вы поместите свои данные в git, вы можете доверять факту, что через пять лет после того, как он преобразуется из вашего жесткого диска в DVD в любую новую технологию, и вы скопировали его, пять лет спустя вы может проверить данные, которые вы получаете обратно, - это те же самые данные, которые вы ввели. И это то, что вы действительно должны искать в системе управления исходным кодом.

Обновление от 2017 года с помощью Git 2.16 (Q1 2018): это усилие для поддержки альтернативного SHA продолжается: см. "Почему Git не использует более современные SHA?".

Я упомянул в Как Git обрабатывать столкновение SHA-1 на блобе?", которое вы могли бы создать фиксацию с определенным префиксом SHA1 (все еще чрезвычайно дорогостоящие усилия).
Но точка остается, поскольку Эрик Санк упоминает в " Git: Криптографические хеши "(Версия управления версиями (2011):

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

Труднее найти хороший некризисный хэш с низкой скоростью столкновения, если вы не рассматриваете исследование типа " Поиск современных некриптографических хэшей с генетическим программированием.

Вы также можете прочитать "Рассмотрим использование некриптографического хеш-алгоритма для ускорения хеширования ", в котором упоминается, например, " xxhash ", чрезвычайно быстрый некриптографический алгоритм Hash, работающий на скоростях, близких к ограничениям RAM.

Обсуждения вокруг изменения хэша в Git не новы:

• либо чтобы оптимизировать его (август 2009 г.), но вам нужно принять лицензионную версию:

(Линус Торвальдс)

На самом деле ничего не осталось от кода мозиллы, но эй, я начал с него. Оглядываясь назад, я, вероятно, должен был начать с кода asm PPC, который уже сделал блокировку благоразумно, но это "вещь 20/20 задним числом".

Плюс эй, код мозиллы, представляющий собой ужасную груду crud, был почему я был настолько убежден, что смог улучшить ситуацию. Так что это своего рода источник для него, даже если он больше касается мотивационной стороны, чем любой существующий оставшийся код;)

И вам нужно быть осторожным в как измерить фактическое увеличение эффективности

(Линус Торвальдс)

Я в значительной степени могу гарантировать, что он улучшит ситуацию только потому, что он создает gcc-код, который затем скрывает некоторые проблемы P4.

• или изменить его вообще (январь 2010 г.)
  (например, SHA-3, но это относится к любому другому хэшу):

(Джон Тапсель - johnflux)

Стоимость разработки Git от SHA-1 до нового алгоритма намного выше. Я не уверен, как это можно сделать хорошо.

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

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

Короче говоря, переключиться на любой хеш непросто.

Обновление февраля 2017 года: да, теоретически возможно вычислить встречный SHA1: shattered.io

Как влияет Git?

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

Но:

Эта атака потребовала более 9,223,372,036,854,775,808 SHA1 вычислений. Это обеспечило эквивалентную вычислительную мощность как 6500 лет одноцентровых вычислений и 110-летних вычислений с одним GPU.

Так что пусть еще не паникует.
См. Больше в разделе Как Git обрабатывать столкновение SHA-1 на блобе?.