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 на крапку? ".