Ответ 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 на блобе?.