Я представил этот ход в " Почему Git не использует более современный SHA? " в Авг. 2018
Причины были обсуждены здесь Брайаном М. Карлсоном:
Я реализовал и протестировал следующие алгоритмы, все из которых 256 бит (в алфавитном порядке):
- BLAKE2b (libb2)
- BLAKE2bp (libb2)
- KangarooTwelve (импортировано из пакета кода Keccak)
- SHA-256 (OpenSSL)
- SHA-512/256 (OpenSSL)
- SHA3-256 (OpenSSL)
- SHAKE128 (OpenSSL)
Я также отклонил некоторых других кандидатов.
Я не смог найти ни ссылки, ни реализации SHA256 × 16, поэтому я не реализовал ее.
Я не рассматривал SHAKE256, потому что он почти идентичен до SHA3-256 практически по всем характеристикам (включая производительность).
SHA-256 и SHA-512/256
Это 32-битные и 64-битные алгоритмы SHA-2, которые Размер 256 бит.
Я отметил следующие преимущества:
- Оба алгоритма хорошо известны и тщательно проанализированы.
- Оба алгоритма обеспечивают устойчивость к 256-битным изображениям.
Сводка
Алгоритмы с наибольшей доступностью реализации: SHA-256, SHA3-256, BLAKE2b и SHAKE128.
С точки зрения доступности командной строки BLAKE2b, SHA-256, SHA-512/256 и SHA3-256 должны быть доступны в ближайшем будущем при достаточно небольшой установке Debian, Ubuntu или Fedora.
Что касается безопасности, наиболее консервативными являются варианты SHA-256, SHA-512/256 и SHA3-256.
Победителями в производительности являются BLAKE2b без ускорения и ускорение SHA-256.
Предлагаемый вывод основывался на :
Популярность
При прочих равных условиях мы должны быть склонны к тому, что широко используется & рекомендуется для новых проектов.
Аппаратное ускорение
Единственное широко распространенное ускорение HW - для SHA-1 и SHA-256 из семейства SHA-2 , но ничего особенного Семейство ewer SHA-3 (выпущено в 2015 году).
Возраст
По аналогии с «популярностью», кажется, лучше склонять вещи к хэшу, который существовал некоторое время, то есть слишком рано выбирать SHA-3.
План перехода ha sh, когда-то реализованный, также облегчает переход на что-то другое в будущем , поэтому мы не должны в ru sh, чтобы выбрать более новый га sh, потому что нам нужно сохранить его навсегда, мы всегда можем сделать еще один переход через 10-15 лет.
Результат: commit 0ed8d8d , Git v2.19.0-rc0, 4 августа 2018.
SHA-256 имеет ряд преимуществ:
Он существует уже некоторое время, широко используется и поддерживается практически каждой криптографической библиотекой (OpenSSL, mbedTLS, CryptoNG, SecureTransport и др. c).
При сравнении с SHA1D C большинство векторизованных реализаций SHA-256 действительно быстрее, даже без ускорения.
Если мы делаем подписи с OpenPGP (или даже, я полагаю, CMS), мы будем использовать SHA-2, поэтому не имеет смысла, чтобы наша безопасность зависела от двух отдельные алгоритмы, когда один из них может нарушить безопасность, когда мы можем просто зависеть от одного.
Так что SHA-256 это так.
Идея остается: любое понятие SHA1 удаляется из Git кодовой базы и заменяется обобщенной c "ha sh" переменной.
Завтра, что ha sh будет SHA2, но код будет поддерживать другие хэши в будущем.
Как Линус Торвальдс деликатно выражает это (выделено мной):
Честно говоря, число частиц в наблюдаемой вселенной составляет порядка 2 ** 256. Это действительно очень большое число.
Не делайте базу кода более сложной, чем нужно.
Примите обоснованное техническое решение и скажите: «256 бит - это лот * 1117». * ".
Разница между теорией и теорией в том, что инженерия делает компромисс.
Хорошее программное обеспечение хорошо разработано , а не теоретизировано .
Кроме того, Я бы предложил git по умолчанию "abbrev-commit=40", чтобы никто на самом деле не видел новых битов по умолчанию .
Так что perl scripts et c, использующие "[0-9a-f]{40}" в качестве шаблона ha sh, просто молча продолжат работать.
Поскольку обратная совместимость важна (*)
(*) И 2 ** 160 - все еще большое большое число, и на самом деле это не было практической проблемой, и SHA1D C, вероятно, будет хорошим га sh на следующее десятилетие или дольше.
(SHA1D C, для "Обнаружения (?) Столкновения"), было обсуждено в начале 2017 года , после того, как атака столкновения разбилась вдребезги .io экземпляр: см. commit 28dc98e , Git v2.13.0-rc0, март 2017, от Джефф Кинг и столкновение " Ha sh в git ")
Подробнее см. Documentation/technical/hash-function-transition.txt
Переход на SHA-256 может быть выполнен одним локальным хранилищем
а. Не требуя никаких действий со стороны другой стороны.
b. Репозиторий SHA-256 может взаимодействовать с серверами SHA-1 Git (push / fetch).
c. Пользователи могут использовать идентификаторы SHA-1 и SHA-256 для объектов взаимозаменяемо (см. «Имена объектов в командной строке» ниже).
d. Новые подписанные объекты используют более надежную функцию ha sh, чем SHA-1, для своих гарантий безопасности.
Этот переход облегчается с помощью Git 2.27 (Q2 2020) и его git fast-import --rewrite-submodules-from/to=<name>:<file>
См. commit 1bdca81 , commit d9db599 , commit 11d8ef3 , commit abe0cc5 , commit ddddf8d , commit 42d4e1d , commit e02a714 , commit efa7ae3 , commit 3c9331a , commit 8b8f718 , commit cfe3917 , commit bf154a8 , commit 8dca7f3 , commit 6946e52 , commit 8bd5a29 , commit 1f5f8f3 , коммит 192b517 , коммит 9412759 , коммит 61e2a70 , коммит dadacf1 , коммит 768e30e , коммит 2078991 (22 февраля 2020 г.) Брайан М. Карлсон (bk2204) .
(Объединено Junio C Hamano - gitster - в коммит f8cb64e , 27 марта 2020 г. )
fast-import: добавить опции для перезаписи подмодулей
Подписано: brian m. carlson
При преобразовании хранилища с использованием подмодулей из одного алгоритма ha sh в другой необходимо переписать подмодули из старого алгоритма в новый алгоритм, поскольку только ссылки на подмодули , а не их содержимое, записываются в поток быстрого экспорта .
Без перезаписи подмодулей происходит быстрый импорт с ошибкой «Invalid dataref» при обнаружении подмодуля в другом алгоритме.
Добавьте пару параметров --rewrite-submodules-from и --rewrite-submodules-to, которые принимают список меток, создаваемых fast-export и fast-import, соответственно, при обработке субмодуля.
Используйте эти метки для сопоставления коммитов субмодуля из старый алгоритм к новому алгоритму.
Мы читаем метки в два соответствующих объекта struct mark_set, а затем выполняем отображение из старого в новое, используя таблицу ha sh. Это позволяет нам повторно использовать тот же код синтаксического анализа меток, который используется в другом месте, и позволяет нам эффективно читать и сопоставлять метки на основе их идентификатора, поскольку файлы меток не нужно сортировать.
Обратите внимание, что поскольку мы используем таблицу khash для идентификаторов объектов, и эта таблица копирует значения struct object_id вместо того, чтобы ссылаться на них, необходимо обнулить значения struct object_id, которые мы используем вставить и посмотреть в таблице. В противном случае мы получили бы значения SHA-1, которые не совпадают из-за того, что мусор стека может остаться в неиспользуемой области.
Документация git fast-import сейчас включает в себя:
Перезапись подмодуля
--rewrite-submodules-from=<name>:<file>
--rewrite-submodules-to=<name>:<file>
Переписать идентификаторы объектов для подмодуля, заданного <name>, из значений, используемых в from <file>, в значения, используемые в to <file>.
Метки from должны были быть созданы git fast-export, а метки to должны были быть созданы git fast-import при импорте того же субмодуля.
<name> может быть любой произвольной строкой, не содержащей символа двоеточия, но одно и то же значение должно использоваться с обеими опциями при указании соответствующих меток.
Можно указать несколько подмодулей с разными значениями для. Ошибочно не использовать эти параметры в соответствующих парах.
Эти параметры в первую очередь полезны при преобразовании хранилища из одного алгоритма ha sh в другой; без них быстрый импорт завершится неудачно, если он встретит подмодуль, потому что не может записать идентификатор объекта в новый алгоритм ha sh.
И:
commit: использовать ожидаемый заголовок подписи для SHA-256
Подписано: brian m. Карлсон
План перехода предполагает, что мы позволим подписи использовать несколько алгоритмов в одном коммите .
Для этого нам нужно использовать другой заголовок для алгоритм, чтобы было очевидно, по каким данным вычислять сигнатуру.
План перехода определяет, что мы должны использовать "gpgsig-sha256", поэтому подключите код коммитов так, чтобы он мог записывать и анализировать текущий алгоритм, и он может удалить заголовки для любого алгоритма при создании нового коммита.
Добавить тесты, чтобы убедиться, что мы пишем, используя правильный заголовок, и что git fsck не отклоняет эти коммиты.