Hash collision w git


175

Co by się właściwie stało, gdybym miał kolizję hash podczas korzystania z git?

Np. Udaje mi się zatwierdzić dwa pliki z tą samą sumą kontrolną sha1, czy git to zauważy lub uszkodzi jeden z plików?

Czy można ulepszyć git, aby z tym żyć, czy też musiałbym zmienić na nowy algorytm mieszania?

(Proszę nie odwracać tego pytania, omawiając, jak mało prawdopodobne jest to - dziękuję)


26
I've been informed by the git Gods that the chances of a SHA1 collision is the same as the Earth being sucked up into the black hole created by the CERN accelerator. If this is indeed true, then there's no need for that extra memcmp. , źródło: lwn.net/Articles/307281
KurzedMetal

16
ABSOLUTNIE NIE TAK. Cytując Dana Bernsteina: „Fakt, że naukowcy nie przeprowadzili jeszcze ataku kolizyjnego SHA-1, jest drobnym historycznym wypadkiem” - teraz, gdy konkurs SHA-3 dobiegł końca, istnieje duża szansa, że ​​odpowiednie osoby zwrócą ich uwagę wykorzystanie znanego ataku do spowodowania kolizji. Marc Stevens szacuje trudność na zaledwie 2 ^ 61 operacji. Bardzo prawdopodobne, że wkrótce nastąpi zderzenie SHA-1; dziwne, że to się już nie wydarzyło.
Paul Crowley,

27
@KurzedMetal: Jest szansa na powstanie czarnej dziury w CERN (dwa protony zderzyłyby się dokładnie (10 ^ -15m)), ale ta czarna dziura nie zasysałaby Ziemi, natychmiast wyparowałaby pod wpływem promieniowania Hawkinga ... szanse na kolizję SHA1 są znacznie większe niż wessanie ... tylko mówienie ...
Jaa-c


17
To zdumiewające, że specjalnie poprosiłeś ludzi, aby nie rozmawiali o nieprawdopodobieństwie zderzenia gitów, a prawie wszyscy mówili o tym nieprawdopodobieństwie. Tym ludziom należy zakazać przepełnienia stosów na całe życie!
Yukio Fukuzawa

Odpowiedzi:


108

Zbieranie atomów na 10 księżycach

Skrót SHA-1 to ciąg 40 znaków szesnastkowych ... czyli 4 bity na znak pomnożone przez 40 ... 160 bitów. Teraz wiemy, że 10 bitów to w przybliżeniu 1000 (dokładnie 1024), co oznacza, że ​​istnieje 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 różnych skrótów SHA-1 ... 10 48 .

Co to jest odpowiednik? Cóż, Księżyc składa się z około 10 47 atomów. Więc jeśli mamy 10 księżyców ... i losowo wybierzesz jeden atom na jednym z tych księżyców ... a potem idź dalej i wybierz ponownie losowy atom na nich ... wtedy prawdopodobieństwo, że wybierzesz ten sam atom dwa razy , to prawdopodobieństwo, że dwa podane zatwierdzenia git będą miały ten sam skrót SHA-1.

Rozwijając to, możemy zadać pytanie ...

Ile zatwierdzeń potrzebujesz w repozytorium, zanim zaczniesz martwić się o kolizje?

Dotyczy to tak zwanych „ataków urodzinowych”, co z kolei odnosi się do „Paradoksu urodzinowego” lub „Problemu urodzinowego”, który mówi, że kiedy wybierasz losowo z danego zestawu, potrzebujesz zaskakująco niewielu typów, zanim będzie bardziej prawdopodobne wybrać coś dwa razy. Ale „zaskakująco mało” jest tutaj bardzo względnym terminem.

Wikipedia ma tabelę prawdopodobieństwa kolizji Paradoksu urodzinowego . Nie ma wpisu dla 40-znakowego skrótu. Ale interpolacja wpisów dla 32 i 48 znaków daje nam wynik w zakresie 5 * 10 22 git commits z prawdopodobieństwem 0,1% kolizji. To pięćdziesiąt miliardów miliardów różnych zobowiązań, czyli pięćdziesiąt Zettacommitów , zanim osiągniesz nawet 0,1% szansy na kolizję.

Suma bajtów samych skrótów dla tych zatwierdzeń oznaczałaby więcej danych niż wszystkie dane wygenerowane na Ziemi przez rok, co oznacza, że ​​musiałbyś generować kod szybciej niż YouTube przesyła strumieniowo wideo. Powodzenia z tym. :RE

Chodzi o to, że jeśli ktoś celowo nie powoduje kolizji, prawdopodobieństwo przypadkowego zdarzenia jest tak oszałamiająco małe, że można zignorować ten problem

„Ale gdy kolizja nie występuje, to co rzeczywiście się dzieje?”

Ok, przypuśćmy, że zdarzy się nieprawdopodobne, lub przypuśćmy, że komuś udało się dostosować celową kolizję hash SHA-1 . Co się wtedy stanie?

W takim przypadku jest doskonała odpowiedź, gdy ktoś na niej eksperymentował . Cytuję z tej odpowiedzi:

  1. Jeśli obiekt BLOB już istnieje z tym samym hashem, nie otrzymasz żadnych ostrzeżeń. Wygląda na to, że wszystko jest w porządku, ale kiedy naciskasz, ktoś klonuje lub cofasz, stracisz najnowszą wersję (zgodnie z tym, co wyjaśniono powyżej).
  2. Jeśli obiekt drzewa już istnieje i utworzysz obiekt blob z tym samym hashem: wszystko będzie wydawać się normalne, dopóki nie spróbujesz wypchnąć lub ktoś nie sklonuje repozytorium. Wtedy zobaczysz, że repozytorium jest uszkodzone.
  3. Jeśli obiekt zatwierdzenia już istnieje i tworzysz obiekt blob z tym samym hashem: tak samo jak # 2 - uszkodzony
  4. Jeśli obiekt BLOB już istnieje i utworzysz obiekt zatwierdzenia z tym samym skrótem, aktualizacja „ref” zakończy się niepowodzeniem.
  5. Jeśli obiekt blob już istnieje i utworzysz obiekt drzewa z tym samym hashem. Nie powiedzie się podczas tworzenia zatwierdzenia.
  6. Jeśli obiekt drzewa już istnieje i utworzysz obiekt zatwierdzenia z tym samym hashem, aktualizacja „ref” nie powiedzie się.
  7. Jeśli obiekt drzewa już istnieje i utworzysz obiekt drzewa z tym samym hashem, wszystko będzie wyglądać dobrze. Ale kiedy zatwierdzisz, całe repozytorium odniesie się do niewłaściwego drzewa.
  8. Jeśli obiekt zatwierdzenia już istnieje i utworzysz obiekt zatwierdzenia z tym samym hashem, wszystko będzie wyglądać dobrze. Ale kiedy zatwierdzisz, zatwierdzenie nigdy nie zostanie utworzone, a wskaźnik HEAD zostanie przeniesiony do starego zatwierdzenia.
  9. Jeśli obiekt zatwierdzenia już istnieje i utworzysz obiekt drzewa z tym samym hashem, zakończy się niepowodzeniem podczas tworzenia zatwierdzenia.

Jak się wydaje, niektóre przypadki nie są dobre. Szczególnie przypadki nr 2 i 3 powodują bałagan w repozytorium. Wydaje się jednak, że błąd pozostaje w tym repozytorium, a atak / dziwaczne nieprawdopodobieństwo nie rozprzestrzenia się do innych repozytoriów.

Wydaje się również, że kwestia celowych kolizji jest uznawana za realne zagrożenie, dlatego np. GitHub podejmuje działania, aby temu zapobiec .


22
Nie wiem, czy liczby są dokładne, ale rany, to świetny graficzny sposób na opisanie nieprawdopodobieństwa i zabawny :)
mimoralea

4
Jestem w kontakcie z NASA, aby znaleźć 10 księżyców i wypróbować to. O ile nie mamy 10 księżyców, nikt nie mówi, czy to działa;)
Utkarsh Kumar

2
Prawdopodobieństwo, że przypadkowe zatwierdzenie rzeczywistego pliku tekstowego zderzy się, jest równe zeru, bardzo mało prawdopodobne. Ale ta odpowiedź całkowicie pomija fakt, że ktoś mógłby próbować celowo doprowadzić do kolizji. Wraz z atakiem na skrót SHA-1 staje się to raczej ważnym czynnikiem.
Maarten Bodewes

7
Powód głosowania negatywnego: bardzo ładnie powiedziane, ale prawdopodobieństwo nie ma tu absolutnie żadnego znaczenia. To samo można powiedzieć o wygrywaniu w lotto, ale ludzie wygrywają w lotto tu i tam na co dzień. Więc firma lotto nie może tak po prostu powiedzieć: szansa jest niewielka, więc nie powinniśmy się martwić o faktyczną wypłatę jackpota. Pytanie OP brzmi: co się dzieje, gdy pojawia się ta mała szansa, a ty nie odpowiedziałeś.
Yukio Fukuzawa

3
@FukuzawaYukio Nie wydrukowano jednak 2 ^ 48 losów na loterię - tylko miliony (może 200 milionów łącznie rocznie… kto wie?) I jest zwycięska loteria. Prawdopodobieństwo jest znacznie większe, a w przypadku niektórych losów na loterię zawsze drukowany jest zwycięski kupon; więc zwycięzca jest nieunikniony (chyba że zwycięski kupon zostanie przypadkowo umieszczony w niewłaściwym miejscu). Ponadto wiele lat temu stworzyłem pseudo-realistyczną loterię: lottery.py . Nie trzeba dodawać, że tracisz 99% czasu.
dylnmc

67

Jeśli dwa pliki mają tę samą sumę skrótu w git, potraktuje te pliki jako identyczne. W absolutnie mało prawdopodobnym przypadku, gdy tak się stanie, zawsze możesz cofnąć się o jedno zatwierdzenie i zmienić coś w pliku, aby już nie kolidowały ...

Zobacz post Linusa Torvaldsa w wątku „Zaczynasz myśleć o sha-256?” na liście mailingowej git .


4
„Jeśli dwa pliki mają tę samą sumę skrótu w git, potraktuje te pliki jako identyczne”. To jest właściwie prawidłowa odpowiedź. Czy jednak masz jakieś źródło tego oświadczenia klaustophera? Twój link nie działa dla mnie.
Tiago

3
Ale nie jest to absolutnie nieprawdopodobne, jeśli pracujesz nad projektem z kolekcją próbek kolizji hashów.
Doomjunky

6
@JBishop Nie, nie. Jeśli masz dowód na kolizję hash, zyskasz natychmiastową sławę. Nie zapomnij go opublikować! Wyślę skrzynkę naprawdę dobrego piwa Haarlem, jeśli pokażesz mi pełnowymiarową kolizję haszyszu SHA-1 utworzoną w Git w ciągu tygodnia. Zwróć uwagę, że musi to być oddzielna kolizja hash, która nie została już cytowana w innym miejscu (nie oznacza to, że ktoś jeszcze ją opublikował, ale nadal).
Maarten Bodewes

7
+1 Jedyna jak dotąd odpowiedź, która faktycznie odpowiada na pytanie. Cała reszta to tylko bełkot o „małej szansie”, która może się zdarzyć, o czym każdy programista już wie.
Yukio Fukuzawa

2
Uważaj na Linusa omawiającego bezpieczeństwo IT - mylił się wcześniej, a myli się co do tego. Gdyby ktoś mógł dowolnie tworzyć kolizje SHA-1, można by go używać do wszelkiego rodzaju chaosu, takiego jak tworzenie cyklicznych historii, które powodują awarie serwerów i klientów Git.
DomQ,

26

Naprawdę nie można odpowiedzieć na to pytanie właściwym „ale” bez wyjaśnienia, dlaczego nie stanowi to problemu. Nie da się tego zrobić bez naprawdę dobrego uchwycenia tego, czym naprawdę jest haszysz. Jest to bardziej skomplikowane niż proste przypadki, na które mógłbyś zostać narażony w programie CS.

Istnieje tutaj podstawowe nieporozumienie dotyczące teorii informacji. Jeśli zredukujesz dużą ilość informacji do mniejszych poprzez odrzucenie pewnej ilości (np. Hash), może wystąpić kolizja bezpośrednio związana z długością danych. Im krótsze dane, tym MNIEJ prawdopodobne. Teraz zdecydowana większość kolizji będzie bełkotem, co znacznie zwiększa prawdopodobieństwo ich wystąpienia (nigdy nie sprawdziłbyś bełkotu ... nawet obraz binarny jest nieco ustrukturyzowany). W końcu szanse są nikłe. Aby odpowiedzieć na twoje pytanie, tak, git potraktuje je jako takie same, zmiana algorytmu haszującego nie pomoże, zajmie jakieś „drugie sprawdzenie”, ale ostatecznie będziesz potrzebować tyle danych „dodatkowego sprawdzenia” ponieważ długość danych jest w 100% pewna ... pamiętaj, że będzie to 99,99999 .... do naprawdę długiej liczby cyfr ... pewnie za pomocą prostego czeku, jak opisałeś. SHA-x to skróty o dużej mocy kryptograficznej, co oznacza, że ​​celowe utworzenie dwóch zestawów danych źródłowych, które są BARDZO PODOBNE i mają ten sam skrót, zazwyczaj nie jest trudne. Jeden bit zmiany w danych powinien spowodować utworzenie więcej niż jednego (najlepiej jak najwięcej) bitów zmiany w danych wyjściowych skrótu, co również oznacza, że ​​bardzo trudne (ale nie całkiem niemożliwe) jest powrót od skrótu do pełnego zestawu zderzeń, a tym samym wyciągnie oryginalną wiadomość z tego zestawu kolizji - wszystkie oprócz kilku będą bełkotem, a tych, których nie ma, wciąż jest ogromna liczba do przeszukania, jeśli długość wiadomości jest znacząca. Wadą skrótu kryptograficznego jest to, że wolno je oblicza ... ogólnie.

Więc co to wszystko oznacza dla Gita? Niewiele. Hashy są wykonywane tak rzadko (w stosunku do wszystkiego innego), że ich koszt obliczeniowy jest ogólnie niewielki w przypadku operacji. Szanse na zderzenie z parą kolizji są tak niskie, że nie jest to realistyczna szansa na wystąpienie i nie zostanie wykryte natychmiast (tj. Twój kod najprawdopodobniej nagle przestałby się budować), co pozwala użytkownikowi naprawić problem (wykonać kopię zapasową wersji, i dokonaj zmiany ponownie, a prawie na pewno otrzymasz inny hash ze względu na zmianę czasu, który również zasila hash w git). Jest bardziej prawdopodobne, że będzie to dla ciebie prawdziwy problem, jeśli przechowujesz dowolne pliki binarne w git, co nie jest tym, czym jest jego podstawowy model użycia. Jeśli chcesz to zrobić ... prawdopodobnie lepiej będzie, jeśli skorzystasz z tradycyjnej bazy danych.

Nie ma nic złego w myśleniu o tym - to dobre pytanie, które wielu ludzi po prostu uważa za „tak mało prawdopodobne, że nie warto o tym myśleć” - ale to naprawdę trochę bardziej skomplikowane. Jeśli tak się stanie, powinno być bardzo łatwe do wykrycia, nie będzie to ciche uszkodzenie w normalnym przepływie pracy.


4
you'll almost certainly get a different hash because of the time change, which also feeds the hash in gitCzy hash nie jest oparty wyłącznie na zawartości pliku?
fredoverflow

4
Skrót obiektu blob jest oparty na zawartości pliku (z niewielką ilością metadanych), jednak skrót zatwierdzenia (który teoretycznie może również kolidować) zawiera aktualny czas, a także skrót drzewa, autor, skróty zatwierdzeń rodzica itp. Jednak, jak zauważył @Steve, małe rzeczy są mniej podatne na kolizję, a zatwierdzenie jest małą rzeczą.
cdyson37

1
Nie myśl, że zgadzam się ze stwierdzeniem „Im krótsze dane, tym MNIEJ prawdopodobne będzie [kolizje]”. Jeśli masz na myśli krótsze skróty, to zmniejszasz zestaw możliwych skrótów = więcej mapowania danych wejściowych do każdego skrótu = większa szansa na kolizję. Jeśli masz na myśli krótsze wiadomości, które haszujesz, to jest to prawdą tylko w tym sensie, że liczba możliwych danych wejściowych jest ograniczona liczbą użytych znaków, co wydaje się tak oczywiste, że czuję, że chyba nie rozumiem.
Podstawowy

Nigdy nie myślałem o punkcie „BARDZO PODOBNYM”, który jest naprawdę dobry. Zasadniczo oznacza to, że aby mieć 2 zatwierdzenia z tym samym hashem, musiałbyś zmienić znaczną część znaków w każdym pliku (nie wspominając o nazwach plików, ścieżkach i liczbie plików).
PieterNuyts

1
@PieterNuyts Nie, aby uzyskać określony skrót z dowolnego pliku początkowego, zazwyczaj musiałbyś zmienić informacje w pliku o kwotę podobną do liczby bitów informacji w hashu, tj. Około 160 bitów dla SHA-1. Jednak liczy się również informacja o tym, które bity zmienić, więc im dłuższy plik, tym mniej bitów trzeba zmienić, jeśli wybierzesz prawidłowe. Hipotetycznie, biorąc pod uwagę plik o długości znacznie powyżej 2 ^ 160 bajtów, można uzyskać prawie każdy hash, zmieniając jeden bit, ponieważ lokalizacja tego bitu zawiera ponad 160 bitów informacji!
M Kloster,

10

Czy można ulepszyć git, aby z tym żyć, czy też musiałbym zmienić na nowy algorytm mieszania?

Kolizje są możliwe w przypadku dowolnego algorytmu wyznaczania wartości skrótu, więc zmiana funkcji skrótu nie wyklucza problemu, a jedynie zmniejsza prawdopodobieństwo jego wystąpienia. Więc powinieneś wybrać naprawdę dobrą funkcję skrótu (SHA-1 już jest, ale prosiłeś, aby nie mówić :)


Myślę, że masz na myśli „mniej prawdopodobne” lub „mniej prawdopodobne”, prawda? Pewnie, że mógłby zmienić algorytm hash z mniej bajtów danych wyjściowych, ale nie jest to chodziło, prawda? :)
MichaelK

2
SHA-1 jest zepsuty w tym sensie, że stanie się możliwe tworzenie celowych kolizji haszyszu. Myślę, że to było już w 2012 roku. Tak więc zmiana na inny hash, który jest bezpieczniejszy i ma większy stan i dane wyjściowe, z pewnością zrobiłby różnicę.
Maarten Bodewes

9

Możesz zobaczyć dobre studium w „ Jak Git poradziłby sobie z kolizją SHA-1 na obiekcie blob? ”.

Ponieważ kolizja SHA1 jest teraz możliwa (o czym odnoszę się w tej odpowiedzi w shattered.io ), wiedz, że Git 2.13 (Q2 2017) poprawi / złagodzi obecną sytuację dzięki wariantowi „wykrywania próby stworzenia kolizji” implementacji SHA-1 autorzy: Marc Stevens (CWI) i Dan Shumow (Microsoft) .

Zobacz zatwierdzenie f5f5e7f , zatwierdzenie 8325e43 , zatwierdzenie c0c2006 , zatwierdzenie 45a574e , zatwierdzenie 28dc98e (16 marca 2017) autorstwa Jeffa Kinga ( peff) .
(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu 48b3693 , 24 marca 2017 r.)

Makefile: ustaw DC_SHA1jako domyślne

Kiedyś domyślnie używaliśmy implementacji SHA1 z biblioteki OpenSSL.
Ponieważ staramy się uważać na ataki kolizyjne po ostatnim ogłoszeniu „shattered”, zmień ustawienie domyślne, aby zachęcić ludzi do korzystania z implementacji DC_SHA1.
Ci, którzy chcą użyć implementacji z OpenSSL, mogą wprost o to poprosić, OPENSSL_SHA1=YesPleaseuruchamiając " make".

W rzeczywistości nie mamy kolizji obiektu Git, więc najlepsze, co możemy zrobić, to uruchomić jeden z zniszczonych plików PDF za pomocą testu-sha1. Powinno to uruchomić kontrolę kolizji i zginąć.


Czy można ulepszyć Git, aby z tym żyć, czy też musiałbym zmienić na nowy algorytm mieszania?

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? ”.

Będziesz mógł użyć innego algorytmu mieszania: SHA1 nie jest już jedynym algorytmem Git.


Git 2.18 (Q2 2018) dokumentuje ten proces.

Zobacz zatwierdzenie 5988eb6 , zobowiązanie 45fa195 (26 marca 2018) autorstwa Ævara Arnfjörð Bjarmason ( avar) .
(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu d877975 , 11 kwietnia 2018)

doc hash-function-transition: wyjaśnij, co oznacza SHAttered

Spróbuj wyjaśnić, co w praktyce oznacza atak SHAttered dla Git.
W poprzedniej wersji tekstu nie było żadnej wzmianki o tym, że Git już posiada środki łagodzące dla tego konkretnego ataku, co według naukowców SHAttered pozwoli wykryć kryptoanalityczne ataki kolizyjne.

Być może pomyliłem się w niektórych niuansach, ale o ile wiem, ten nowy tekst dokładnie podsumowuje obecną sytuację z SHA-1 w git. To znaczy, że git tak naprawdę nie używa już SHA-1, używa Hardened-SHA-1 (tak się składa, że ​​produkują te same wyniki 99,99999999999 ...% czasu).

Tak więc poprzedni tekst był błędny, twierdząc, że:

[...] W wyniku [SHAttered], SHA-1 nie może być już uważane za bezpieczne kryptograficznie [...]

To nie o to chodzi. Mamy środki zaradcze przeciwko SHAttered, jednak uważamy, że rozsądne jest podjęcie działań w kierunku NewHashpojawienia się przyszłych luk w SHA-1 lub Hardened-SHA-1.

Tak więc nowa dokumentacja brzmi teraz:

Git v2.13.0, a później został domyślnie przeniesiony do wzmocnionej implementacji SHA-1, która nie jest podatna na atak SHAttered.

Tak więc Git w efekcie już migrował do nowego skrótu, który nie jest SHA-1 i nie ma wspólnych luk w zabezpieczeniach, jego nowa funkcja skrótu po prostu tworzy dokładnie takie same dane wyjściowe dla wszystkich znanych danych wejściowych, z wyjątkiem dwóch plików PDF opublikowanych przez SHAttered badaczy, a nowa implementacja (napisana przez tych badaczy) twierdzi, że wykrywa przyszłe kryptoanalityczne ataki kolizyjne.

Niezależnie od tego, rozważne jest przejście od dowolnego wariantu SHA-1 do nowego skrótu. Nie ma gwarancji, że przyszłe ataki na SHA-1 nie zostaną opublikowane w przyszłości, a ataki te mogą nie mieć wykonalnych środków zaradczych.

Gdyby SHA-1 i jego warianty były naprawdę zepsute, funkcja skrótu Gita nie mogłaby być już uważana za bezpieczną kryptograficznie. Miałoby to wpływ na przekazywanie wartości skrótu, ponieważ nie mogliśmy ufać, że dana wartość skrótu reprezentuje znaną dobrą wersję treści, zgodnie z zamierzeniami głośnika.

Uwaga: ten sam dokument (Q3 2018, Git 2.19) wyraźnie odwołuje się do „nowego skrótu” jako SHA-256 : zobacz „ Dlaczego Git nie używa nowocześniejszego SHA? ”.


4
To jedyna przyzwoita odpowiedź lub komentarz tutaj. Podsumowując - choć niezwykle mało prawdopodobne, jest to możliwe. Zostałyby one również natychmiast niemożliwe do zidentyfikowania i naprawione poprzez poprawienie pliku (z komentarzem), aby uniknąć kolizji. Uważa się, że celowe exploity są nieistotne, ponieważ ktoś mógłby równie łatwo sprawdzić „zły kod” - a są takie rzeczy, jak podpisy i celowe żądania ściągnięcia, aby proceduralnie uniemożliwić przypadkowym osobom sprawdzanie przypadkowych rzeczy.
Brad

5

Google twierdzi teraz, że kolizja SHA-1 jest możliwa pod pewnymi warunkami wstępnymi: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Ponieważ git używa SHA-1 do sprawdzania integralności plików, oznacza to, że integralność plików w git jest zagrożona.

IMO, git zdecydowanie powinien użyć lepszego algorytmu haszującego, ponieważ teraz możliwa jest celowa kolizja.


2
Rozsądnie byłoby też nie ufać słowom Linusa dotyczącym bezpieczeństwa komputera. Mylił się wcześniej, a co do tego się myli. (Na przykład, SHA-1 Collision Oracle pozwala tworzyć jeden okrągły popełnić historie awarię serwerów i klientów podobne)
DomQ

2

Kolizja haszyszu jest tak mało prawdopodobna, że ​​jest po prostu oszałamiająca! Naukowcy na całym świecie bardzo się starają, aby to osiągnąć, ale jeszcze im się to nie udało. Jednak w przypadku niektórych algorytmów, takich jak MD5, odniosły sukces.

Jakie są szanse?

SHA-256 ma 2 ^ 256 możliwych skrótów. To około 10 ^ 78 . Lub mówiąc bardziej obrazowo, szanse na kolizję są bliskie

1: 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

Szansa na wygranie loterii wynosi około 1:14 mln . Szansa na kolizję z SHA-256 jest jak wygrana w loterii przez 11 kolejnych dni !

Wyjaśnienie matematyczne: 14000000 ^ 11 ~ 2 ^ 256

Ponadto wszechświat ma około 10 ^ 80 atomów. To tylko 100 razy więcej niż jest kombinacji SHA-256.

Udana kolizja MD5

Nawet w przypadku MD5 szanse są niewielkie. Chociaż matematykom udało się stworzyć kolizję:

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 8 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 7 1415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 b 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 a 80d1e c69821bcb6a88393 96f965 2 b6ff72a70

ma taką samą MD5 jak

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 0 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 f 1415a 085125e8f7cdc99f d91dbd7280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 3 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 2 80d1e c69821bcb6a88393 96f965 a b6ff72a70

Nie oznacza to, że MD5 jest mniej bezpieczny teraz, gdy jego algorytm został złamany. Możesz celowo tworzyć kolizje MD5, ale szansa na przypadkową kolizję MD5 wciąż wynosi 2 ^ 128, czyli wciąż dużo.

Wniosek

Nie musisz się martwić o kolizje. Algorytmy haszujące to drugi najbezpieczniejszy sposób sprawdzania identyczności plików. Jedynym bezpieczniejszym sposobem jest porównanie binarne.


4
Ta odpowiedź dotyczy głównie SHA-256, co jest nieistotne, ponieważ pytanie dotyczyło SHA-1. Matematyka pokazująca nieprawdopodobieństwo kolizji SHA-256 jest dużo bardziej optymistyczna niż wynikałoby z SHA-1. Nadal jest bardzo mało prawdopodobne, ale odpowiedź SHA-1 byłaby bardziej odpowiednia.
Andrew Arnott

@AndrewArnott Nie ma istotnej różnicy między SHA-256 i SHA-1. SHA-1 jest 2 ^ 128 razy słabszy, ale to też nie ma znaczenia. Nadal nie można go złamać, więc moja odpowiedź nie jest tak błędna.
bytecode77

4
SHA-1 jest rzeczywiście zepsuty, więc stwierdzenie, że jest „nadal nie do złamania”, jest również błędne. Biorąc pod uwagę, że SHA-1 jest w rzeczywistości zepsuty, ktoś mógłby celowo zaatakować algorytm sha-1 gita w celu zastąpienia treści bez wykrycia. SHA-256 nie został jeszcze uszkodzony, więc byłby bezpieczniejszy. Dlatego odpowiedź na pytanie o potencjalne kolizje gitów najlepiej pozostawić do SHA-1.
Andrew Arnott

„Nie oznacza to, że MD5 jest mniej bezpieczny teraz, gdy jego algorytm został złamany”. Wracać? Czy mógłbyś wyjaśnić to zdanie?
Maarten Bodewes

Powód odpowiedzi: ponieważ istnieje wiele zamieszania wśród osób, które nie są zaznajomione z komputerami, a mimo to lądują tutaj po przeszukaniu sieci. Z mojego doświadczenia wynika, że ​​błędne przekonania na temat „szyfrowania a moc obliczeniowa” są bardziej powszechne niż myślisz, więc potraktowałem to jako dodatkowe informacje.
bytecode77


1

Niedawno znalazłem post z 29.04.2013 w grupie dyskusyjnej BSD pod adresem

http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html

gdzie plakat głosi:

Raz wpadłem na kolizję hash, używając git rebase.

Niestety, nie przedstawia żadnego dowodu na swoje roszczenie. Ale może chciałbyś spróbować się z nim skontaktować i zapytać o ten rzekomy incydent.

Ale na bardziej ogólnym poziomie, z powodu ataku urodzinowego, szansa na zderzenie z hashem SHA-1 wynosi 1 w pow (2, 80).

Brzmi to dużo i na pewno znacznie więcej niż całkowita liczba wersji poszczególnych plików obecnych we wszystkich repozytoriach Git na świecie razem wzięta.

Jednak dotyczy to tylko wersji, które faktycznie pozostają w historii wersji.

Jeśli deweloper w dużym stopniu polega na ponownym bazowaniu, za każdym razem, gdy rebase jest uruchamiany dla gałęzi, wszystkie zatwierdzenia we wszystkich wersjach tej gałęzi (lub zmienionej części gałęzi) otrzymują nowe skróty. To samo dotyczy każdego pliku modyfikowanego przez „git filter-branch”. Dlatego „rebase” i „filter-branch” mogą być dużymi mnożnikami liczby haszów generowanych w czasie, mimo że nie wszystkie z nich są w rzeczywistości zachowywane: Często po zmianie bazy (szczególnie w celu „oczyszczenia” gałęzi ), oryginalna gałąź jest wyrzucana.

Ale jeśli kolizja nastąpi podczas rozgałęzienia rebase lub filtru, nadal może mieć niekorzystne skutki.

Inną rzeczą byłoby oszacowanie całkowitej liczby zahaszowanych obiektów w repozytoriach git i sprawdzenie, jak daleko są one od pow (2, 80).

Powiedzmy, że mamy około 8 miliardów ludzi, a wszyscy z nich korzystaliby z gita i przechowowaliby swoje wersje w 100 repozytoriach git na osobę. Załóżmy dalej, że przeciętne repozytorium ma 100 zatwierdzeń i 10 plików, a tylko jeden z tych plików zmienia się na zatwierdzenie.

Dla każdej wersji mamy co najmniej skrót dla obiektu drzewa i samego obiektu zatwierdzenia. Razem ze zmienionym plikiem mamy 3 skróty na wersję, a zatem 300 skrótów na repozytorium.

Dla 100 repozytoriów 8 miliardów ludzi daje to pow (2, 47), który wciąż jest daleki od pow (2, 80).

Nie obejmuje to jednak rzekomego efektu mnożenia wspomnianego powyżej, ponieważ nie jestem pewien, jak uwzględnić go w tym oszacowaniu. Może mogłoby to znacznie zwiększyć szanse na kolizję. Zwłaszcza jeśli bardzo duże repozytoria, które mają długą historię zatwierdzeń (jak jądro Linuksa), są ponownie bazowane przez wiele osób w celu wprowadzenia drobnych zmian, które jednak tworzą różne skróty dla wszystkich zatwierdzonych zmian.


Ciekawy. +1. Jak wspomniałem powyżej, ten problem w końcu zniknie: stackoverflow.com/a/47838703/6309
VonC,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.