Вероятно, этого еще никогда не случалось в реальном мире, и, возможно, никогда не случится, но давайте рассмотрим это: скажем, у вас есть git-репозиторий, сделайте коммит, и вам очень очень не повезло: один из BLOB-объектов заканчивается тем же SHA-1 как другой, который уже находится в вашем хранилище. Вопрос в том, как Git справится с этим? Просто потерпеть неудачу? Найдите способ связать два блоба и проверить, какой из них нужен в соответствии с контекстом?
Больше дразнилка, чем реальная проблема, но я нашел проблему интересной.
git
hash-collision
Gnurou
источник
источник
Ответы:
Я провел эксперимент, чтобы выяснить, как именно Git будет вести себя в этом случае. Это с версией 2.7.9 ~ rc0 + next.20151210 (версия Debian). Я просто уменьшил размер хеша со 160-битного до 4-битного, применив следующий diff и перестроив git:
Затем я сделал несколько коммитов и заметил следующее.
Для # 2 вы, как правило, получаете ошибку, подобную этой, когда вы запускаете "git push":
или:
если вы удалите файл, а затем запустите "git checkout file.txt".
Для № 4 и № 6 вы, как правило, получите ошибку, подобную этой:
при запуске "git commit". В этом случае вы можете просто снова набрать «git commit», так как это создаст новый хеш (из-за измененной метки времени)
Для № 5 и № 9 вы обычно получаете сообщение об ошибке, подобное этому:
при запуске "git commit"
Если кто-то попытается клонировать ваш поврежденный репозиторий, он обычно увидит что-то вроде:
Меня «беспокоит» то, что в двух случаях (2,3) хранилище становится поврежденным без каких-либо предупреждений, а в 3 случаях (1,7,8) все выглядит нормально, но содержимое хранилища отличается от того, что вы ожидаете быть. У людей, клонирующих или тянущих, будет другое содержание, чем у вас. Случаи 4,5,6 и 9 в порядке, так как остановится с ошибкой. Я полагаю, было бы лучше, если бы это не удалось с ошибкой, по крайней мере, во всех случаях.
источник
Оригинальный ответ (2012) (см.
shattered.io
Столкновение SHA1 2017 ниже)Этот старый (2006 г.) ответ Линуса все еще может быть актуален:
Вопрос об использовании SHA-256 регулярно упоминается, но не действует на на текущем (2012).
Примечание: начиная с 2018 года и Git 2.19 , код подвергается рефакторингу для использования SHA-256.
Примечание (юмор): вы можете принудительно зафиксировать конкретный префикс SHA1 с помощью gitbrute проекта от Брэда Фицпатрика (
bradfitz
) .Пример: https://github.com/bradfitz/deadbeef
Даниэль Динниес указывает в комментариях на 7.1 Git Tools - Revision Selection , который включает в себя:
Даже совсем недавно (февраль 2017 года) была
shattered.io
продемонстрирована возможность создания столкновения SHA1:(см. Гораздо больше в моем отдельном ответе , в том числе в посте Линуса Торвальдса в Google+)
Смотрите " Время жизни криптографических хеш-функций " от Валери Аниты Авроры для получения дополнительной информации.
На этой странице она отмечает:
Смотрите больше в моем отдельном ответе ниже .
источник
/* This line added to avoid collision */
: D вы можете выиграть в лотерею дважды: P/* This line added to avoid collision of the avoid collision line */
По словам Pro Git :
Так что это не подведет, но и не сохранит ваш новый объект.
Я не знаю, как это будет выглядеть в командной строке, но это, безусловно, сбивает с толку.
Чуть дальше эта же ссылка пытается проиллюстрировать вероятность такого столкновения:
источник
Чтобы добавить к моему предыдущему ответу от 2012 года , теперь есть (февраль 2017 года, пять лет спустя) пример фактического столкновения SHA-1 с shattered.io , где вы можете создать два сталкивающихся PDF-файла: получить SHA- 1 цифровая подпись на первом файле PDF, которая также может использоваться как действительная подпись на втором файле PDF.
Смотрите также « У дверей смерти в течение многих лет, широко используемая функция SHA1 теперь мертва », и эта иллюстрация .
Обновление от 26 февраля: Линус подтвердил следующие пункты в посте Google+ :
Относительно этого перехода см. Git 2.16 Q1 2018, в котором добавлена структура, представляющая алгоритм хеширования. Осуществление этого перехода началось.
Начиная Git 2.19 (Q3 2018) , Git выбрал SHA-256 в качестве NewHash и находится в процессе интеграции его в код (то есть SHA1 по-прежнему используется по умолчанию (Q2 2019, Git 2.21), но SHA2 будет преемником)
Оригинальный ответ (25 февраля) Но:
Это имеет некоторые проблемы,
git-svn
хотя . Вернее с самим svn , как видно здесь .git fsck
, как уже упоминал Линус Торвальдс, сегодня.git fsck
предупреждает о коммит-сообщении с непрозрачными данными, скрытыми после aNUL
(хотяNUL
не всегда присутствует в мошенническом файле ).Не все включаются
transfer.fsck
, но делает GitHub: любой толчок будет прерван в случае неправильного формирования объекта или разрыва ссылки. Хотя ... есть причина, по которой она не активирована по умолчанию .Актуальная проблема при создании двух репозиториев Git с одинаковым хешем коммитов и разным содержимым. И даже тогда атака остается запутанной .
Джои Хесс пробует эти PDF в репозитории Git, и он обнаружил :
Таким образом, основным вектором атаки (подделка коммита) будет :
Кроме того, вы уже можете и обнаруживать криптоаналитические атаки на SHA-1, присутствующие в каждом файле с
cr-marcstevens/sha1collisiondetection
Добавление аналогичной проверки в Git само по себе потребует некоторых вычислений .
Об изменении хэша Linux комментирует :
Тем не менее, план перехода (от SHA1 к другой хэш-функции) все еще будет сложным , но активно изучается. Кампания находится в стадии разработки :
convert-to-object_id
Обновление 20 марта: GitHub подробно описывает возможную атаку и ее защиту :
Степень защиты:
Смотри "
sha1collisiondetection
" Марк СтивенсСнова, с Q1 2018 Git 2.16, добавляющего структуру, представляющую алгоритм хеширования, началась реализация перехода к новому хешу.
Как упоминалось выше, новый поддерживаемый хэш будет SHA-256 .
источник
git-svn
хотя» относится к нему, хотя и косвенно)Я думаю, что криптографы будут праздновать.
Цитата из статьи Википедии о SHA-1 :
источник
y
такую, чтоh(x) ==
h (y) `, которая представляет серьезную угрозу для произвольных данных, таких как сертификаты SSL, однако это не влияет на Git, который будет уязвим для второй атаки перед изображением, что означает, что имея сообщение,x
вы можете изменить его на сообщение,x'
чтоh(x) == h(x')
. Так что эта атака не ослабляет Git. Также Git не выбрал SHA-1 по соображениям безопасности.Существует несколько различных моделей атак на хэши, например SHA-1, но обычно обсуждается поиск коллизий, включая инструмент Марка Стивенса « HashClash» .
Как указали люди, вы можете вызвать хеш-коллизию с git, но это не приведет к перезаписи существующих объектов в другом хранилище. Я думаю, что даже
git push -f --no-thin
не будет перезаписывать существующие объекты, но не уверен на 100%.Тем не менее, если вы взломать удаленный репозиторий , то вы можете сделать ваш ложный объект старше одного там , возможно встраивание взломанный код в исходный проект с открытым на GitHub или аналогичный. Если вы были осторожны, возможно, вы могли бы представить взломанную версию, которую загружали новые пользователи.
Однако я подозреваю, что многие вещи, которые могут сделать разработчики проекта, могут либо разоблачить, либо случайно уничтожить ваш взломанный многомиллионный взлом. В частности, это огромные деньги, если какой-то разработчик, которого вы не взломали, когда-либо запускает вышеупомянутое
git push --no-thin
после изменения созданных файлов, иногда даже без--no-thin
зависимости.источник