Ответ 1

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

См. Сообщение Linus Torvalds в теме "Начать думать о ша-256?" в списке рассылки git.

Ответ 2

Хэш SHA-1 представляет собой строку с шестнадцатеричным символом 40... это 4 бита на символ каждые 40... 160 бит. Теперь мы знаем, что 10 бит составляют приблизительно 1000 (1024, если быть точным), что означает, что существует 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 различных хешей SHA-1... 10 ⁴⁸.

Что это за эквивалент? Ну, Луна состоит из атомов порядка 10 ⁴⁷. Итак, если у нас 10 лун... и вы случайно выбираете один атом на одной из этих лун... и затем продолжайте и снова выберите случайный атом... тогда вероятность того, что вы выберете тот же атом дважды, является вероятность того, что две команды git будут иметь один и тот же SHA-1 хэш.

РЕДАКТИРОВАТЬ: Расширение этого... сколько коммитов вам нужно в репозитории, прежде чем вы начнете беспокоиться о столкновениях? Это относится к так называемым "Дня рождения", который, в свою очередь, относится к "Парадоксам дня рождения", в котором говорится, что, когда вы выбираете случайным образом из заданного набора, вам нужно удивительно мало выбора, прежде чем вы выбрали что-то дважды. Но "удивительно мало" здесь очень относительный термин.

Wikipedia имеет таблицу на этом. Нет записи для хэша с 40 символами. Но интерполяция записей для 32 и 48 персонажей приземляется в диапазоне 5 * 10 ²² git, фиксирует вероятность столкновения на 0,1%. Это пятьдесят тысяч миллиардов миллиардов битков, или пятьдесят Zettacommits, прежде чем вы достигнете даже 0,1% вероятности столкновения.

Байт-сумма только хэшей для этих коммитов будет больше данных, чем все данные, сгенерированные на Земле в течение года, то есть вам нужно будет выкидывать код быстрее, чем потоки видео YouTube. Удачи с этим.: D

Ответ 3

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

Существует фундаментальное непонимание теории информации здесь. Если вы уменьшите большой объем информации до меньшего количества, отбросив некоторую сумму (т.е. Хеш), вероятность столкновения будет напрямую связана с длиной данных. Чем короче данные, тем меньше вероятность, что это будет. Теперь подавляющее большинство столкновений будет тарабарщиной, что делает их гораздо более вероятными на самом деле (вы никогда не будете проверять тарабарщину... даже двоичный образ несколько структурирован). В конце концов, шансы удалены. Чтобы ответить на ваш вопрос, да, git будет относиться к ним как к одному и тому же, изменение алгоритма хеширования не поможет, оно займет некоторую "вторую проверку", но в конечном итоге вам понадобится столько "дополнительной проверки" "данные, поскольку длина данных должна быть на 100% уверенной... помните, что вы были бы 99.99999.... на очень длинное количество цифр... уверен с простой проверкой, как вы описываете. SHA-x - криптографически сильные хеши, что означает, что обычно трудно преднамеренно создать два набора данных источника, которые оба очень похожи друг на друга и имеют одинаковый хеш. Один бит изменения данных должен создать более одного (желательно как можно большего) бита изменения хэш-вывода, что также означает, что очень сложно (но не совсем невозможно) отработать от хэша до полного набора столкновений и, тем самым, вытащить исходное сообщение из этого набора коллизий - все, кроме нескольких, будут тарабарщиной, а из тех, которые еще не имеют большого количества просеиваний, если длина сообщения имеет значительную длину. Недостатком крипто хэша является то, что они медленно вычисляют... в общем.

Итак, что все это значит для Git? Немного. Хеши делают так редко (по сравнению со всем остальным), что их вычислительный штраф невелик в целом по отношению к операциям. Шансы столкновения пары столкновений настолько низки, что это не реальный шанс произойти и не быть обнаружен сразу (т.е. Ваш код, скорее всего, внезапно перестанет строиться), позволяя пользователю исправить проблему (создать резервную копию ревизии, и сделайте изменение снова, и вы почти наверняка получите другой хеш из-за изменения времени, который также подает хэш в git). Вероятнее всего, для вас это будет реальной проблемой, если вы храните произвольные двоичные файлы в git, что на самом деле не является тем, что используется для первичной модели использования. Если вы хотите это сделать... вам, вероятно, лучше использовать традиционную базу данных.

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

Ответ 4

Можно ли улучшить git, чтобы жить с этим, или мне нужно перейти на новый алгоритм хеширования?

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

Ответ 5

Google теперь утверждает, что столкновение SHA-1 возможно при определенных предварительных условиях: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Так как git использует SHA-1 для проверки целостности файла, это означает, что целостность файла в git скомпрометирована.

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

Ответ 6

Столкновение хэшей настолько маловероятно, что это чистый ум! Ученые во всем мире стараются достичь одного, но пока не справились. Однако для некоторых алгоритмов, таких как MD5, они были успешными.

Каковы шансы?

SHA-256 имеет 2 ^ 256 возможных хэшей. Это примерно 10 ^ 78. Или, чтобы быть более графическим, вероятность столкновения составляет около

1:100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

Вероятность выигрыша в лотерее - 1:14 Mio. Вероятность столкновения с SHA-256 похожа на выигрыш в лотерее на 11 дней подряд!

Математическое объяснение: 14 000 000 ^ 11 ~ 2 ^ 256

Кроме того, universe имеет около 10 ^ 80 атомов. Это всего в 100 раз больше, чем комбинации SHA-256.

Успешное столкновение MD5

Даже для MD5 шансы крошечные. Хотя математикам удалось создать столкновение:

d131dd02c5e6eec4 693d9a0698aff95c 2fcab58712467eab 4004583eb8fb7f89
55ad340609f4b302 83e488832571415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2b487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080a80d1e c69821bcb6a88393 96f9652b6ff72a70

имеет тот же MD5, что и

d131dd02c5e6eec4 693d9a0698aff95c 2fcab50712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325f1415a 085125e8f7cdc99f d91dbd7280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e23487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080280d1e c69821bcb6a88393 96f965ab6ff72a70

Это не значит, что теперь MD5 менее безопасен, когда его алгоритм взломан. Вы можете создавать конфликты MD5 с целью, но вероятность случайного столкновения MD5 по-прежнему составляет 2 ^ 128, что по-прежнему много.

Заключение

Вам не нужно беспокоиться о столкновениях. Алгоритмы хеширования - второй безопасный способ проверки идентичности файлов. Единственный безопасный способ - двоичное сравнение.

Ответ 7

Ну, я думаю, теперь мы знаем, что произойдет - вы должны ожидать, что ваш репозиторий будет поврежден (source).

Ответ 8

Вы можете увидеть хорошее исследование в Как Git обрабатывать столкновение SHA-1 на блобе?".

Так как теперь возможно столкновение SHA1 (как я ссылаюсь в на этот ответ с shattered.io), знайте, что Git 2.13 (Q2 2017) улучшит/смягчит текущую ситуацию с помощью варианта "обнаружить попытку создания коллизий" реализация SHA-1 Марком Стивенсом (CWI) и Дэном Шумовом (Microsoft).

См. commit f5f5e7f, commit 8325e43, commit c0c2006, commit 45a574e, commit 28dc98e (16 марта 2017 г.) Джефф Кинг (peff).
^{(объединено Junio ​​C Hamano - gitster - в commit 48b3693, 24 марта 2017 г.}

Makefile: make DC_SHA1 по умолчанию

Мы использовали реализацию SHA1 из библиотеки OpenSSL по умолчанию.
Поскольку мы стараемся быть осторожными против столкновений после недавнего "разломанного" объявления, переключите значение по умолчанию, чтобы побудить людей использовать реализацию DC_SHA1 вместо этого. Те, кто хочет использовать реализацию OpenSSL, могут он OPENSSL_SHA1=YesPlease при запуске "make".

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

Можно ли улучшить Git, чтобы жить с этим, или мне нужно перейти на новый алгоритм хеширования?

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

Вы сможете использовать другой алгоритм хеширования: SHA1 уже не единственный для Git.