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

TLDR;

• С 2005 по 2018 год/Git 2.18:ша-1 (см. ниже)
• 2019, переключится в какой-то момент до SHA-256

---

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

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

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

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

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

---

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

---

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

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

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

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

---

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

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

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

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

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

и вы должны быть осторожны о как измерить фактический прирост оптимизации

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

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

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

(Иоанна Тапселл - johnflux)

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

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

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

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

---

обновление февраль 2017: Да, теоретически можно вычислить столкновение SHA1: shattered.io

Как влияет GIT?

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

но:

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

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