switch - git tag vs branch




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

Я читал о том, что Git использует дайджест SHA-1 как идентификатор для ревизии. Почему он не использует более современную версию SHA?


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

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

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

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

См. Коммит c250e02 (28 ноября 2017 г.) от Ramsay Jones (``) .
См. Коммит eb0ccfd , коммит 78a6766 , коммит f50e766 , коммит abade65 (12 ноября 2017 г.) от brian m. Карлсон ( bk2204 ) .
(Объединено Junio ​​C Hamano - gitster - в коммите 721cc43 , 13 декабря 2017 г.)

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

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

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

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

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

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

В будущих версиях Git мы планируем поддерживать дополнительный алгоритм хеширования.
Интегрируйте перечисление алгоритмов хеширования с настройкой хранилища и сохраните указатель на перечисленные данные в хранилище структуры .
Конечно, в настоящее время мы поддерживаем только SHA-1, поэтому жестко read_repository_format это значение в 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 ) .
(Объединено Джунио К Хамано - gitster - в коммите 34f2297 , 20 августа 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):

См. Коммит 0d7c419 , коммит dda6346 , коммит eccb5a5 , коммит 93eb00f , коммит d8a3a69 , коммит fbd0e37 , коммит f690b6b , коммит 49d1660 , коммит 268babd , коммит fa13080 , коммит 7b5e614 , коммит 58ce21b , коммит 2f0c25a9e9e9 , f9306b , коммит 2f0c259e9 , Карлсон ( bk2204 ) .
См. Коммит 6afedba (15 октября 2018 г.) от SZEDER Gábor ( szeder ) .
(Объединено с Junio ​​C Hamano - gitster - в коммите d829d49 , 30 октября 2018 г.)

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

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

GIT_SHA1_HEXSZ далее GIT_SHA1_HEXSZ / заменяется Git 2.22 (Q2 2019) и фиксирует d4e568b .

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

См. Коммит 4b4e291 , коммит 27dc04c , коммит 13eeedb , коммит c166599 , коммит 37649b7 , коммит a2ce0a7 , коммит 50c817e , коммит 9a3a0ff , коммит 0dab712 , коммит 47edb64 (14 ноября 2018 г.) и коммит 2f90b9d , коммит 1ccf07c (22 октября 2019 г.) (22 октября 201 ) , Карлсон ( bk2204 ) .
(Объединено Junio ​​C Hamano - gitster - в коммите 33e4ae9 , 29 января 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 МБ / с.

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

Модернизация продолжается с Git 2.24 (Q4 2019)

См. Коммит aaa95df , коммит be8e172 , коммит 3f34d70 , коммит fc06be3 , коммит 69fa337 , коммит 3a4d7aa , коммит e0cb7cd , коммит 8d4d86b , коммит f6ca67d , коммит dd336a5 , коммит 894c0f6 , коммит 4439c7a , коммит 976407 , коммит ef9958 703d2d4 , коммит 9d958cc , коммит 7962e04 , коммит fee4930 (18 августа 2019 г.) по Брайану m. Карлсон ( bk2204 ) .
(Объединено Джунио С. Хамано - gitster - в коммите 676278f , 11 октября 2019 г.)

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


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

Рассматриваются некоторые хэши SHA-256, SHA-512/256, SHA-256x16, K12 и BLAKE2bp-256


ОБНОВЛЕНИЕ : Приведенный выше вопрос и этот ответ относятся к 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 больше ,

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

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





sha