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

TLDR;

• С 2005 по 2018 год / Git 2.18:ша-1 (см. ниже)
• 2019, переключится в какой-то момент to 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 на капле?" что вы мог бы инженер фиксации с определенным 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: разбита.io

Как влияет GIT?

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

но:

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

Так что давайте пока не паниковать.
Подробнее см. В разделе"как Git справится с столкновением SHA-1 на капле?".