Почему Git не использует более современный SHA?

Ответ 1

  Почему он не использует более современную версию SHA?

Декабрь 2017: будет. И Git 2.16 (Q1 2018) - первый выпуск, иллюстрирующий и реализующий это намерение.

Примечание: см. Git 2.19 ниже: это будет SHA-256.

Git 2.16 предложит инфраструктуру для определения того, какая хеш-функция используется в Git, и начнет работу по ее внедрению в различные пути кода.

Смотрите коммит c250e02 (28 ноября 2017 г.) от Рамси Джонс ('').
Смотрите коммит eb0ccfd, коммит 78a6766, коммит f50e766, коммит abade65 (12 ноября 2017 г.) от brian m. Карлсон (bk2204).
^{(Merged by Junio C Hamano -- [TG41] -- in commit 721cc43, 13 Dec 2017)}

Добавить структуру, представляющую алгоритм хеширования

Поскольку в будущем мы хотим поддерживать дополнительный алгоритм хеширования, добавьте структуру, которая представляет алгоритм хеширования, и все данные, которые должны сопровождать его,.
Добавьте константу , чтобы упростить перечисление алгоритмов хеширования.
Реализуйте функцию typedefs, чтобы создать абстрактный API, который может использоваться любым алгоритмом хеширования, и оболочки для существующих функций SHA1, которые соответствуют этому API.

Укажите значение для шестнадцатеричного размера, а также для двоичного размера.
Хотя одно всегда будет вдвое больше другого, оба значения используются чрезвычайно обычно в кодовой базе, и предоставление того и другого приводит к улучшению читабельности.

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

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

Интегрируйте поддержку алгоритма хеширования с настройкой репо

В будущих версиях Git мы планируем поддерживать дополнительный хеш Алгоритм.
Интегрируйте перечисление алгоритмов хеширования с настройкой хранилища и сохраните указатель на перечисленные данные в хранилище структуры.
Конечно, в настоящее время мы поддерживаем только SHA-1, поэтому жестко запрограммируйте это значение в read_repository_format.
В будущем мы перечислим это значение из конфигурации.

Добавьте константу the_hash_algo, которая указывает на указатель структуры hash_algo в глобальном хранилище.
Обратите внимание, что это хеш, который используется для сериализации данных на диск, а не хеш, который используется для отображения элементов пользователю.
План перехода предполагает, что они могут отличаться.
Мы можем добавить дополнительный элемент в будущем (скажем, ui_hash_algo), чтобы обеспечить это дело.

Обновление августа 2018 года для Git 2.19 (3-й квартал 2018 года). Git, похоже, выбирает SHA-256 как NewHash.

См. коммит 0ed8d8d (04 августа 2018 г.) Джонатаном Нидером (artagnon).
Смотрите коммит 13f5e09 (25 июля 2018 года) Æвар Арнфьорд Бьярмасон (avar).
^{(Merged by Junio C Hamano -- [TG49] -- in commit 34f2297, 20 Aug 2018)}

doc hash-function-transition: выберите SHA-256 как NewHash

С точки зрения безопасности, кажется, что SHA-256, BLAKE2, SHA3-256, K12 и т.д., Как полагают, имеют схожие свойства безопасности.
Все это хорошие варианты с точки зрения безопасности.

SHA-256 имеет ряд преимуществ:

• Он существует уже некоторое время, широко используется и поддерживается практически каждой криптографической библиотекой (OpenSSL, mbedTLS, CryptoNG, SecureTransport и т.д.).

• При сравнении с SHA1DC большинство векторизованных реализаций SHA-256 действительно быстрее, даже без ускорения.

• Если мы делаем подписи с OpenPGP (или даже, я полагаю, CMS), мы будем использовать SHA-2, поэтому не имеет смысла, чтобы наша безопасность зависела от двух отдельных алгоритмов, когда один из них один может сломать безопасность, когда мы можем просто зависеть от одного.

Так что SHA-256 это.
Обновите документ конструктора hash-function-transition, чтобы так сказать.

После этого патча нет оставшихся экземпляров строки "NewHash", за исключением несвязанного с 2008 года использования в качестве имени переменной в t/t9700/test.pl.

Вы можете увидеть этот переход к SHA 256 в процессе выполнения с Git 2.20 (Q4 2018):

См. commit 0d7c419, commit dda6346, commit eccb5a5, commit 93eb00f, commit d8a3a69, commit fbd0e37, коммит f690b6b, коммит 49d1660, коммит 268babd, коммит fa13080, коммит 7b5e614, зафиксировать 58ce21b, зафиксировать 2f0c9e9, зафиксировать 825544a (15 октября 2018 г.) от Брайан М. Карлсон (bk2204).
Смотрите коммит 6afedba (15 октября 2018 года) СЗЕДЕР ГАБОР (szeder).
^{(Merged by Junio C Hamano -- [TG415] -- in commit d829d49, 30 Oct 2018)}

заменить жестко закодированные константы

Замените несколько основанных на 40 констант ссылками на GIT_MAX_HEXSZ или the_hash_algo, в зависимости от ситуации.
Преобразуйте все использования GIT_SHA1_HEXSZ в использование the_hash_algo, чтобы они подходят для любой длины хэша.
Вместо использования жестко запрограммированной константы для размера шестнадцатеричного идентификатора объекта, переключиться на использование вычисленного указателя из parse_oid_hex, который указывает после идентификатор проанализированного объекта.

GIT_SHA1_HEXSZ дополнительно удален/заменен на Git 2.22 (Q2 2019) и commit d4e568b.

Этот переход продолжается с Git 2.21 (Q1 2019), который добавляет хэш sha-256 и подключает его через код, чтобы позволить сборку Git с помощью "NewHash".

Смотрите commit 4b4e291, commit 27dc04c, commit 13eeedb, commit c166599, commit 37649b7, commit a2ce0a7, зафиксировать 50c817e, зафиксировать 9a3a0ff, зафиксировать 0dab712, зафиксировать 47edb64 (14 ноября 2018 г.) и зафиксировать 2f90b9d, зафиксировать 1ccf07c (22 октября 2018 г.) brian m. Карлсон (bk2204).
^{(Merged by Junio C Hamano -- [TG423] -- in commit 33e4ae9, 29 Jan 2019)}

Добавить базовую реализацию поддержки SHA-256 (февраль 2019 г.)

SHA-1 слаб, и нам нужно перейти к новой хеш-функции.
Некоторое время мы называли эту новую функцию NewHash.
Недавно мы решили выбрать SHA-256 как NewHash.
Причины выбора SHA-256 изложены в этой теме и в истории фиксации для документа перехода хэш-функции.

Добавьте базовую реализацию SHA-256 на основе libtomcrypt, которая находится в общественное достояние.
Оптимизируйте его и реструктурируйте в соответствии с нашими стандартами кодирования.
Извлеките функции update и final из реализации блока SHA-1, поскольку мы знаем, что они правильно работают со всеми компиляторами. Эта реализация медленнее, чем SHA-1, но в будущих коммитах будут представлены более производительные реализации.

Подключите SHA-256 в список алгоритмов хэширования и добавьте тест, который Алгоритм работает правильно.

Обратите внимание, что в этом патче все еще невозможно переключиться на использование SHA-256 в Git.
Дополнительные исправления необходимы для подготовки кода для обработки более крупного алгоритма хеширования, и необходимы дальнейшие исправления теста.

hash: добавить реализацию SHA-256 с использованием OpenSSL

У нас уже есть подпрограммы OpenSSL для SHA-1, поэтому добавьте подпрограммы и для SHA-256.

На Core i7-6600U эта реализация SHA-256 выгодно отличается от реализация SHA1DC SHA-1:

SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408 MiB/s (16 KiB chunks)

sha256: добавить реализацию SHA-256 с помощью libgcrypt

Как правило, производительность криптографических процедур, написанных на ассемблере, выше, чем у C, и это также верно для SHA-256.
Кроме того, большинство дистрибутивов Linux не могут распространять Git, связанный с OpenSSL по причинам лицензирования.

Большинство систем с GnuPG также будут иметь libgcrypt, поскольку это зависимость от GnuPG.
libgcrypt также быстрее, чем реализация SHA1DC для сообщений размером в несколько КиБ и более.

Для сравнения, на Core i7-6600U эта реализация обрабатывает 16 КиБ. куски со скоростью 355 МБ/с, в то время как SHA1DC обрабатывает эквивалентные куски со скоростью 337 MiB/s.

Кроме того, libgcrypt распространяется по лицензии LGPL 2.1, которая является совместим с GPL. Добавьте реализацию SHA-256, которая использует libgcrypt.

Обновление продолжается с Git 2.24 (Q4 2019)

Смотрите коммит aaa95df, коммит be8e172, коммит 3f34d70, коммит fc06be3, коммит 69fa337, коммит 3a4d7aa, commit e0cb7cd, commit 8d4d86b, commit f6ca67d, commit dd336a5, commit 894c0f6, коммит 4439c7a, коммит 95518fa, коммит e84f357, коммит fe9fec4, коммит 976ff7e, коммит 703d2d4, зафиксировать 9d958cc, зафиксировать 7962e04, зафиксировать комиссию 4930 (18 августа 2019 г.) от Брайана М. Карлсон (bk2204).
^{(Merged by Junio C Hamano -- [TG434] -- in commit 676278f, 11 Oct 2019)}

Вместо использования GIT_SHA1_HEXSZ и жестко закодированных констант, переключитесь на используя the_hash_algo.

Ответ 2

ОБНОВЛЕНИЕ: Приведенный выше вопрос и этот ответ относятся к 2015 году. С тех пор Google объявил о первом столкновении SHA-1: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Очевидно, я могу только строить догадки о том, почему Git продолжает использовать SHA-1, но это может быть одной из причин:

1. Git был созданием Линуса Торвальда, и Линус, по-видимому, не хочет заменять SHA-1 другим алгоритмом хеширования.
2. Он делает правдоподобные заявления о том, что успешные атаки на Git на основе столкновений SHA-1 намного сложнее, чем достижение самих столкновений, и, учитывая, что SHA-1 слабее, чем должен быть, не полностью сломлен, что делает его существенно далеким от осуществимая атака по крайней мере сегодня. Кроме того, он отмечает, что "успешная" атака принесет очень мало, если сталкивающийся объект прибудет позже, чем существующий, поскольку более поздний объект будет считаться таким же, как действительный, и игнорируется (хотя другие отмечали, что обратное может произойти).
3. Смена программного обеспечения отнимает много времени и подвержена ошибкам, особенно когда существует существующая инфраструктура и данные, основанные на существующих протоколах, которые необходимо будет перенести. Даже те, кто производит программные и аппаратные продукты, где криптографическая безопасность является единственной точкой системы, все еще находятся в процессе перехода от SHA-1 и других слабых алгоритмов на местах. Просто представьте, что все эти жестко закодированные unsigned char[20] буферы unsigned char[20] повсюду ;-), гораздо проще запрограммировать криптографическую ловкость на старте, чем модифицировать ее позже.
4. Производительность SHA-1 лучше, чем у различных хэшей SHA-2 (вероятно, не так сильно, как сейчас, но может быть препятствием 10 лет назад), а размер хранилища SHA-2 больше,

Некоторые ссылки:

• fooobar.com/questions/2993/...
• Пост группы новостей, в котором показан краткий комментарий Линуса по этому вопросу через пару месяцев после того, как в 2005 году стало известно о главной слабости SHA-1.
• Нить, обсуждающая слабость и возможный переход к ша-256 (с ответами Линуса) в 2006 году
• Заявление NIST об устаревании SHA-1 и рекомендация "быстро перейти к более сильному хеш-функциям SHA-2"

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

Ответ 3

Здесь обсуждается срочность перехода с SHA1 для Mercurial, но это относится и к Git: https://www.mercurial-scm.org/wiki/mpm/SHA1

Короче говоря: если вы не слишком усердны сегодня, у вас гораздо более уязвимые места, чем у sha1. Но, несмотря на это, Mercurial начал более 10 лет назад, чтобы подготовиться к переходу от Sha1.

В течение многих лет велась работа по модернизации структур данных и протоколов Mercurial для преемников SHA1. Место хранения было выделено для больших хэшей в нашей структуре revlog более 10 лет назад в Mercurial 0.9 с введением RevlogNG. Формат bundle2, представленный совсем недавно, поддерживает обмен различными типами хэшей по сети. Единственными оставшимися частями являются выбор функции замены и выбор стратегии обратной совместимости.

Если git не мигрирует из sha1 раньше, чем Mercurial, вы всегда можете добавить другой уровень безопасности, сохранив локальное зеркало Mercurial с помощью hg-git.

Ответ 4

Теперь существует схема перехода к более сильному хешу, поэтому в будущем он будет использовать более современный хеш, чем SHA- 1. Из текущий план перехода:

Некоторые рассматриваемые хеши SHA-256, SHA-512/256, SHA-256x16, K12 и BLAKE2bp-256