Dlaczego Git używa kryptograficznej funkcji skrótu?

Dlaczego Git używa SHA-1 , kryptograficznej funkcji skrótu, zamiast szybszej niekryptograficznej funkcji skrótu?

Powiązane pytanie:

Pytanie o przepełnienie stosu Dlaczego Git używa SHA-1 jako numerów wersji? pyta, dlaczego Git używa SHA-1 w przeciwieństwie do kolejnych liczb dla zatwierdzeń.

TLDR;

• od 2005 do 2018 / Git 2.18: SHA-1 (patrz poniżej)
• 2019 zostanie przełączony w pewnym punkcie na SHA-256

Możesz to sprawdzić od samego Linusa Torvaldsa, gdy przedstawiał Gita Google w 2007 roku :
(moje wyróżnienie)

Sprawdzamy sumy kontrolne uważane za bezpieczne pod względem kryptograficznym. Nikt nie był w stanie złamać SHA-1, ale chodzi o to, że SHA-1, jeśli chodzi o git, nie jest nawet funkcją bezpieczeństwa. To czysta kontrola spójności .
Części zabezpieczające są gdzie indziej. Wiele osób zakłada, że ​​skoro git używa SHA-1, a SHA-1 jest używany do kryptograficznie zabezpieczonych rzeczy, myślą, że jest to ogromna funkcja bezpieczeństwa. Nie ma to nic wspólnego z bezpieczeństwem, to tylko najlepszy hash, jaki możesz zdobyć.

Posiadanie dobrego skrótu jest dobre, aby móc zaufać swoim danym , zdarza się, że ma też inne dobre funkcje, co oznacza, że ​​kiedy haszujemy obiekty, wiemy, że hash jest dobrze rozproszony i nie musimy się martwić o pewne problemy z dystrybucją .

Wewnętrznie oznacza to z punktu widzenia implementacji, że możemy ufać, że hasz jest tak dobry, że możemy używać algorytmów haszujących i wiedzieć, że nie ma złych przypadków.

Jest więc kilka powodów, dla których warto lubić stronę kryptograficzną, ale tak naprawdę chodzi o możliwość zaufania swoim danym.
Gwarantuję Ci, że jeśli umieścisz swoje dane w git, możesz zaufać temu, że pięć lat później, po przekonwertowaniu z dysku twardego na DVD na jakąkolwiek nową technologię i skopiowaniu go razem, pięć lat później możesz zweryfikować dane powrót to dokładnie te same dane, które wprowadziłeś. I jest to coś, czego naprawdę powinieneś szukać w systemie zarządzania kodem źródłowym .

Aktualizacja z grudnia 2017 r. Za pomocą Git 2.16 (I kw. 2018 r.): Trwają prace nad obsługą alternatywnego SHA: zobacz „ Dlaczego Git nie używa nowocześniejszego SHA? ”.

Wspomniałem w „ Jak git poradzi sobie z kolizją SHA-1 na obiekcie blob? ”, Że można zaprojektować zatwierdzenie z określonym prefiksem SHA1 (wciąż jest to niezwykle kosztowne przedsięwzięcie).
Ale sprawa pozostaje, jak wspomina Eric Sink w książce „ Git: Cryptographic Hashes ” ( Kontrola wersji według przykładu (2011) :

Jest raczej ważne, aby DVCS nigdy nie napotkało dwóch różnych fragmentów danych, które mają ten sam skrót. Na szczęście dobre kryptograficzne funkcje skrótu są zaprojektowane tak, aby takie kolizje były niezwykle mało prawdopodobne.

Trudniej jest znaleźć dobry niekryptograficzny hash z niskim współczynnikiem kolizji, chyba że weźmiesz pod uwagę badania typu „ Znajdowanie najnowocześniejszych niekryptograficznych skrótów za pomocą programowania genetycznego ”.

Możesz również przeczytać artykuł „ Rozważ użycie niekryptograficznego algorytmu mieszającego w celu przyspieszenia mieszania ”, w którym wspomniano na przykład „ xxhash ”, niezwykle szybki niekryptograficzny algorytm Hash, działający z prędkością bliską limitom pamięci RAM.

Dyskusje na temat zmiany hasha w Git nie są nowe:

• albo żeby go zoptymalizować (sierpień 2009) , ale musisz wydać licencję:

(Linus Torvalds)

Z kodu Mozilli nie pozostało nic , ale hej, zacząłem od tego. Z perspektywy czasu prawdopodobnie powinienem zacząć od kodu ASM PPC, który już przeprowadził blokowanie rozsądnie - ale to jest coś w rodzaju „20/20”.

Poza tym, hej, kod Mozilli będący okropnym stosem brudu, był powodem, dla którego byłem tak przekonany, że mogę coś poprawić. Więc to jest swego rodzaju źródło, nawet jeśli chodzi bardziej o stronę motywacyjną niż jakikolwiek pozostały kod;)

Musisz też uważać, jak mierzyć rzeczywisty zysk optymalizacji

(Linus Torvalds)

Prawie mogę zagwarantować, że ulepsza to tylko dlatego, że sprawia, że ​​gcc generuje badziewny kod, który następnie ukrywa niektóre problemy z P4.

• lub całkowicie go zmienić (styczeń 2010)
  (na przykład na SHA-3, ale dotyczyłoby to każdego innego skrótu):

(John Tapsell - johnflux)

Koszt inżynierii uaktualnienia git z SHA-1 do nowego algorytmu jest znacznie wyższy . Nie jestem pewien, jak można to zrobić dobrze.

Przede wszystkim prawdopodobnie musimy wdrożyć wersję git (nazwijmy ją wersją 2 dla tej konwersacji), która pozwala na umieszczenie miejsca na nową wartość skrótu, nawet jeśli nie czyta ani nie używa tego miejsca - po prostu używa wartość skrótu SHA-1, która znajduje się w drugim gnieździe.

W ten sposób, gdy w końcu wdrożymy jeszcze nowszą wersję git, nazwijmy ją wersją 3, która oprócz skrótów SHA-1 produkuje skróty SHA-3, osoby używające git w wersji 2 będą mogły nadal współdziałać.
(Chociaż zgodnie z tą dyskusją mogą być podatne na ataki, a osoby, które polegają na ich łatkach tylko z SHA-1, mogą być podatne na ataki).

Krótko mówiąc, przejście na dowolny skrót nie jest łatwe.

Aktualizacja luty 2017: tak, teoretycznie możliwe jest obliczenie kolidującego SHA1: shattered.io

Jaki to ma wpływ na GIT?

GIT silnie opiera się na SHA-1 do identyfikacji i sprawdzania integralności wszystkich obiektów plików i zatwierdzeń.
Zasadniczo możliwe jest utworzenie dwóch repozytoriów GIT z tą samą wartością skrótu head commit i różną zawartością, powiedzmy łagodnym kodem źródłowym i wstecznym.
Osoba atakująca może potencjalnie selektywnie udostępniać dowolne repozytorium docelowym użytkownikom. Będzie to wymagało od atakujących obliczenia własnej kolizji.

Ale:

Ten atak wymagał ponad 9.223.372.036.854.775.808 obliczeń SHA1. Wymagało to równoważnej mocy obliczeniowej 6500 lat dla obliczeń z jednym procesorem i 110 lat dla obliczeń z jednym procesorem GPU.

Więc nie panikujmy jeszcze.
Więcej informacji znajdziesz w artykule „ Jak Git poradziłby sobie z kolizją SHA-1 na obiekcie blob? ”.