Чому Git використовує криптографічну хеш-функцію?


139

Чому Git використовує SHA-1 , криптографічну хеш-функцію, замість швидшої некриптографічної хеш-функції?

Питання, пов'язані з цим:

Питання про переповнення стека Чому Git використовує SHA-1 як номери версій? запитує, чому Git використовує SHA-1 на відміну від послідовних номерів для комітетів.


Особисто я вважаю, що навіть використання розбитого SHA-1 над SHA-2 було передчасною оптимізацією.
CodesInChaos

7
@CodesInChaos: і крім того, введення будь-якого конкретного алгоритму в код було жахливим порушенням принципів DI. Має бути десь у конфігураційному файлі XML ;-)
Стів Джессоп

Оновіть грудень 2017 року з Git 2.16 (1 квартал 2018 року): триває спроба підтримати альтернативну SHA: див. " Чому Git не використовує більш сучасний SHA? ".
VonC

Немає хороших 160-бітових або вищих некриптових хешів. Більшість - це оптимізовані 32-бітні, 64-бітні або 128-бітні функції. 128-біт - це добре, але я відчуваю, що 128-бітний дещо низький для такого великого проекту, як git. Якби швидко, якісний 224/256-бітний хеш вийшов, це, мабуть, було б ідеально.
bryc

Відповіді:


197

TLDR;


Це можна перевірити від самого Лінуса Торвальда, коли він презентував Git в Google ще в 2007 році :
(акцент мій)

Ми перевіряємо контрольні суми, які вважаються криптографічно захищеними. Ніхто не зміг зламати SHA-1, але справа в тому, що SHA-1, що стосується git, не є навіть функцією захисту. Це суто перевірка консистенції .
Захисні частини знаходяться в іншому місці. Багато людей припускають, оскільки git використовує SHA-1, а SHA-1 використовується для криптографічно безпечних речей, вони вважають, що це величезна функція безпеки. Це не має нічого спільного з безпекою, це просто найкращий хеш, який ви можете отримати.

Хороший хеш - це користь для довіри вашим даним , у нього буває і деякі інші хороші функції, це означає, що коли ми хеш-об’єкти, ми знаємо, що хеш добре розподілений, і нам не потрібно турбуватися про певні проблеми з розповсюдженням. .

Всередині це означає, що з точки зору реалізації, ми можемо вірити, що хеш настільки хороший, що ми можемо використовувати алгоритми хешування і знаємо, що немає поганих випадків.

Отже, є деякі причини, що теж подобаються криптографічній стороні, але це справді стосується здатності довіряти своїм даним.
Я гарантую вам, що якщо ви помістите свої дані в git, ви можете довіряти тому, що через п'ять років після перетворення з жорсткого диска на DVD в будь-яку нову технологію, і ви скопіювали їх разом, через п'ять років ви зможете перевірити дані, які ви Вийти назад - це ті самі дані, які ви ввели. І це те, що вам справді слід шукати в системі управління вихідним кодом .


Оновіть грудень 2017 року за допомогою Git 2.16 (1 квартал 2018 р.): Намагання щодо підтримки альтернативної SHA триває: див. " Чому Git не використовує більш сучасний SHA? ".


Я згадував у " Як би Git впорався зіткненням SHA-1 на крапку? ", Що ти можеш створити команду з певним префіксом SHA1 (все ще надзвичайно дороге починання).
Але справа залишається, як Ерік Сінк згадує у книзі " Git: Cryptographic Hashes " ( Контроль версій за прикладом (2011)) :

Досить важливо, щоб DVCS ніколи не стикався з двома різними фрагментами даних, які мають однаковий дайджест. На щастя, хороші криптографічні хеш-функції створені для того, щоб зробити такі зіткнення вкрай малоймовірними.

Важче знайти хороший некриптографічний хеш із низькою швидкістю зіткнення, якщо не врахувати такі дослідження, як " Пошук найсучасніших некриптографічних хешів із генетичним програмуванням ".

Ви також можете прочитати " Розгляньте використання некриптографічного алгоритму хешування для швидкого хешування ", в якому згадується, наприклад, " xxhash ", надзвичайно швидкий некриптографічний алгоритм хеша , що працює зі швидкістю, близькою до меж оперативної пам'яті.


Дискусії щодо зміни хешу в Git не нові:

(Лінус Торвальдс)

Від коду мозіли насправді нічого не залишилося , але ей, я почав з нього. В ретроспективі я, мабуть, мав би почати з ASM-коду PPC, який вже блокував розумно - але це "річ 20/20".

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

І вам потрібно бути обережними, як вимірювати фактичний приріст оптимізації

(Лінус Торвальдс)

Я в значній мірі можу вам гарантувати, що він покращує речі лише тому, що це змушує gcc генерувати лайний код, який потім приховує деякі проблеми P4.

(Джон Тапселл - johnflux)

Інженерні витрати на модернізацію git з SHA-1 до нового алгоритму значно вищі . Я не впевнений, як це можна зробити добре.

Перш за все, нам, мабуть, потрібно розгорнути версію git (назвемо її версією 2 для цієї розмови), яка дозволяє створити слот для нового значення хеша, навіть якщо він не читає і не використовує цей простір - він просто використовує значення хеша SHA-1, яке знаходиться в іншому слоті.

Таким чином, коли ми врешті-решт розгорнемо ще нову версію git, назвемо її версією 3, яка створює хеші SHA-3 на додаток до хешів SHA-1, люди, які використовують git версії 2, зможуть продовжувати взаємодіяти.
(Хоча в ході цієї дискусії вони можуть бути вразливими, і люди, які покладаються на свої патчі, призначені лише для SHA-1, можуть бути вразливими.)

Коротше кажучи, перейти на будь-який хеш непросто.


Оновлення лютого 2017 року: так, теоретично можливо обчислити зіткнення SHA1: shattered.io

Як впливає GIT?

GIT сильно покладається на SHA-1 для ідентифікації та перевірки цілісності всіх файлових об'єктів та комітетів.
По суті можливо створити два сховища GIT з однаковим хешем фіксації заголовка та різним вмістом, скажімо, доброякісним вихідним кодом та резервним.
Зловмисник потенційно може вибірково обслуговувати будь-яке сховище для цільових користувачів. Для цього зловмисникам потрібно буде обчислити власне зіткнення.

Але:

Ця атака вимагала понад 9,223,372,036,854,775,808 обчислень SHA1. Це зайняло еквівалентну обробну потужність як 6500 років обчислень з одним процесором і 110 років обчислень з одним GPU.

Тож давайте ще не панікувати.
Детальніше дивіться у розділі " Як Git впорався зіткненням SHA-1 на крапку? ".


8
Схоже, нещодавній урожай високоякісних некриптографічних хеш-функцій, як xxhash, вийшов трохи пізно - відразу після git.
Праксеоліт

3
@Praxeolitic дійсно. Були обговорені питання про заміну SHA1 на інший хеш, але це просто потребує небагато роботи, для чого, на даний момент, працює нормально.
VonC

"ми знаємо, що хеш добре розподілений, і нам не потрібно хвилюватися з певних питань розповсюдження" - чому це проблема для scm?
стрижень

@roded швидкість зіткнення є досить низькою, щоб добре підходити для SCM, де дані, як правило, не випадкові, а тестові файли.
VonC

1
Власне, для використання криптографічного хешу є причина безпеки. Коли автор (скажімо, Linus) хоче скоротити реліз (скажімо, Linux), люди хочуть знати вихідний код, який вони завантажують, відповідає тому, що автор мав намір включити у випуск. З цією метою тегується останній хеш комісій у випуску та підписується тег. Якщо ланцюжок хеш-фіксів, що закінчується в тезі, не був би криптографічно захищеним, то джерело можна було б змастити чимось іншим, ніж те, що автор задумав.
Крістофер Кінг
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.