Co sprawia, że ​​algorytm mieszający jest „bezpieczny”?


19

Po przeczytaniu tego interesującego pytania poczułem, że mam dobry pomysł, który niepewny algorytm mieszający użyłbym, gdybym go potrzebował, ale nie mam pojęcia, dlaczego zamiast tego mogę użyć bezpiecznego algorytmu.

Jakie jest zatem rozróżnienie? Czy wynik nie jest tylko liczbą losową reprezentującą zaszyfrowaną rzecz? Co sprawia, że ​​niektóre algorytmy mieszające są bezpieczne?


8
To pytanie jest bardziej odpowiednie dla witryny IT Security SE.
Bernard

@Bernard Jeśli tak jest, nie mam nic przeciwko, ale moje pytanie nie było tak naprawdę na temat tego, jak i kiedy używać bezpiecznego skrótu, ale co odróżnia bezpieczny algorytm mieszania od niepewnego. To wydaje mi się bardziej pytaniem programistycznym, ale nie przeglądam IT Security SE, więc może to też tam działa.
CodexArcanum

2
Bardzo podobne pytanie zostało już zadane na temat bezpieczeństwa IT
ChrisF

Odpowiedzi:


34

Istnieją trzy właściwości, których oczekujemy od każdej funkcji skrótu kryptograficznego H:

  • preimage odporność : Biorąc pod uwagę h, powinno być trudno znaleźć jakąkolwiek wartość xz h = H(x).

  • Drugi opór preimage : Biorąc pod uwagę x1, powinno być trudno znaleźć x2 != x1z H(x1) = H(x2).

  • Odporność na zderzenie : To powinno być trudno znaleźć dwie wartości x1 != x2z H(x1) = H(x2).

W przypadku funkcji skrótu używanych w popularnych językach programowania dla tabel skrótów (ciągów znaków) zwykle nie podano żadnej z nich, zapewniają one tylko:

  • słaba odporność na kolizję : w przypadku losowo (lub „typowo”) wybranych wartości domeny szansa na kolizję jest niewielka. Nie mówi to nic o atakującym, który celowo próbuje tworzyć kolizje lub próbuje znaleźć preimages.

Trzy powyższe właściwości są (wśród) celami projektowania dla każdej funkcji skrótu kryptograficznego. W przypadku niektórych funkcji (takich jak MD4, SHA-0, MD5) wiadomo, że to się nie udało (przynajmniej częściowo). Zakłada się, że obecna generacja (SHA-2) jest bezpieczna, a następna („Bezpieczny algorytm mieszania 3”) jest obecnie w trakcie standaryzacji , po zakończeniu konkursu .

W przypadku niektórych zastosowań (takich jak haszowanie haseł i wyprowadzanie kluczy z haseł) dziedzina faktycznie używanych wartości xjest tak mała, że ​​brutalne wymuszanie tej przestrzeni staje się możliwe dzięki normalnym (szybkim) bezpiecznym funkcjom hashującym i wtedy też chcemy:

  • powolne wykonywanie : Biorąc pod uwagę x, do obliczenia wartości potrzeba minimalnej (najlepiej konfigurowalnej) ilości zasobów H(x).

Ale dla większości innych zastosowań nie jest to pożądane, zamiast tego chce się:

  • szybkie wykonanie : Biorąc pod uwagę x, obliczenie wartości H(x)jest tak szybkie, jak to możliwe (przy jednoczesnym zachowaniu bezpieczeństwa).

Istnieją pewne konstrukcje (takie jak PBKDF2 i scrypt), aby utworzyć powolną funkcję skrótu z szybkiej poprzez częste iterowanie.

Aby uzyskać więcej informacji, spójrz na tag hash na naszej siostrzanej stronie Cryptography Stack Exchange.


3

Bezpieczny oznacza, że ​​ktoś, kto chce wprowadzić cię w błąd przy użyciu kolizji (tj. Fakt, że dwa źródła są połączone tą samą wartością) będzie miał trudności.

Niektóre cechy:

  • znając skrót, zbudowanie pliku, który ma skrót do tej wartości, jest trudne (wariant, część nowego pliku jest podana, a także pożądany skrót)

  • budowanie dwóch różnych plików, których skrót do tej samej wartości jest trudny (podano wariant, część plików)


3

Podstawowa różnica jest dość prosta: normalny skrót ma na celu zminimalizowanie liczby przypadkowych kolizji, o ile jest to możliwe bez spowalniania całego procesu.

Bezpieczny skrót miał zapobiegać kolizjom, nawet jeśli ktoś robi wszystko, aby je wywołać. Zasadniczo nie chcesz wymieniać żadnej możliwości kolizji w celu szybszego działania. W rzeczywistości celowe spowalnianie operacji ma pewne zalety bezpieczeństwa, nawet jeśli nie utrudnia znajdowania kolizji.

Na przykład: jeśli obliczenie skrótu zajmuje 50 ms, nie będzie to miało istotnego wpływu na zwykłe logowanie użytkownika (tzn. Większość użytkowników nie zauważy różnicy 50 ms podczas logowania). Jednocześnie, jeśli atakujący chce wykonać atak słownikowy, możliwość wygenerowania tylko 20 skrótów sekund jest poważnym utrudnieniem. Innymi słowy, z jakiegoś powodu, dla bezpiecznego skrótu, wolniejsze jest lepsze.


3
W dziedzinie kryptograficznych funkcji skrótu istnieją dwie ważne podgrupy: szybkie (używane do uwierzytelniania wiadomości, podpisu i tym podobne) oraz wolne - używane do uzyskiwania kluczy i mieszania hasła. Nie mieszaj ich, są aplikacje dla obu.
Paŭlo Ebermann

W rzeczywistości istnieją również funkcje skrótu zaprojektowane w celu maksymalizacji kolizji: Soundex jest przykładem. Oczywiście sprawia to, że jest to bardzo kiepska, bezpieczna funkcja skrótu.
Jörg W Mittag

@ JörgWMittag: Nie tylko gówniany jako bezpieczny hash, ale byłby również dość kiepski w użyciu z hashowaniem. Z drugiej strony, choć z pewnością nieco haszujący, wahałbym się nazwać Soundex funkcją haszującą, po prostu dlatego, że jego przeznaczenie i zastosowanie jest całkowicie odmienne od normalnych funkcji haszujących.
Jerry Coffin

@JerryCoffin: Myślę, że to zależy od definicji. Np. Angielska strona Wikipedii mówi po prostu, że funkcją skrótu jest dowolny algorytm lub podprogram, który odwzorowuje większy (potencjalnie nieskończony) zestaw dowolnych wartości na mniejszy, skończony zestaw (zwykle skalarnych) wartości. Podczas gdy niemiecka strona Wikipedii mówi, że „mieszanie” (niem. „Zerhacken”) jest integralną częścią, tzn. Że kluczowe znaczenie ma unikanie kolizji i rozkład mapowanych wartości. Soundex bardzo spełnia pierwszą definicję, ale nie drugą.
Jörg W Mittag

3

Przeczytaj ten http://www.codinghorror.com/blog/2012/04/speed-hashing.html , a wszystko wyjaśni znacznie lepiej, niż mógłbym to wyjaśnić. Oto dwa najważniejsze nagłówki w artykule, które bezpośrednio dotyczą twojego pytania:

  • Bezpieczne skróty są zaprojektowane tak, aby były odporne na manipulacje
    • radykalnie zmienia swój wynik za pomocą drobnych zmian bitów w danych wejściowych
  • Bezpieczne skróty mają działać wolno

Jego sekcja TL; DR na końcu:

Jeśli jesteś użytkownikiem:

Upewnij się, że wszystkie hasła mają 12 lub więcej znaków, a najlepiej o wiele więcej. Zalecam stosowanie fraz hasła, które są nie tylko łatwiejsze do zapamiętania niż hasła (jeśli nie są typowe), ale także śmiesznie zabezpieczają się przed brutalnym wymuszaniem wyłącznie ze względu na ich długość.

Jeśli jesteś programistą:

Używaj bcrypt lub PBKDF2 wyłącznie do mieszania wszystkiego, czego potrzebujesz, aby być bezpiecznym. Te nowe skróty zostały specjalnie zaprojektowane, aby były trudne do wdrożenia w procesorach graficznych. Nie używaj żadnej innej formy skrótu. Niemal każdy inny popularny schemat mieszania jest podatny na brutalne wymuszanie przez układy GPU towarowych, które stają się szybsze i bardziej równoległe i łatwiejsze do zaprogramowania na każdy rok.


4
Jeff nie ma racji tutaj w drugim punkcie ... podczas gdy w przypadku niektórych zastosowań (jako skrótu hasła i wyprowadzania klucza z hasła) chcesz być powolny, w przypadku innych zastosowań (takich jak uwierzytelnianie wiadomości, podpisy itp.) Szybki (bezpieczny) funkcje skrótu są dobre.
Paŭlo Ebermann

Masz rację, Paŭlo. Wydajność skrótu zależy od zastosowania skrótu. Jednak powolne mieszanie jest zawsze bezpieczniejsze niż szybkie. Powodem, dla którego użyjesz szybkiego skrótu jest to, że możesz poświęcić bezpieczeństwo dla wydajności.
Nate

2
@Nate „Bardziej bezpieczne” jest zawsze dwuznaczne, ale nawet w przypadku najbardziej charytatywnej aplikacji „powolne mieszanie jest zawsze bezpieczniejsze niż szybkie” jest zdecydowanie błędne. Istnieje wiele aplikacji, w których szybkość mieszania jest nieistotna.
Gilles 'SO - przestań być zły'

@Gilles, czy możesz podać przykład? To właściwie brzmi dla mnie, ale przydałoby się więcej szczegółów.
Nate

2
@Nate Najbardziej oczywistym zastosowaniem skrótów jest weryfikacja integralności kawałka danych: przesyłaj skrót za pośrednictwem bezpiecznego, ale prawdopodobnie o niskiej przepustowości kanału, przesyłaj możliwie duży ładunek przez niepewny kanał, a następnie sprawdź, czy odebrany ładunek ma oczekiwany haszysz. Hashe zajmują również ważne miejsce w metodach podpisywania (w których nie tylko weryfikujesz integralność, ale także kto wysłał ci dane). Hashowanie haseł jest raczej wyjątkiem.
Gilles 'SO - przestań być zły'

2

„Bezpieczny” skrót to skrót, który uważa się za trudny do „sfałszowania” w formalny, powtarzalny sposób bez uprzedniej wiedzy o komunikacie użytym do utworzenia skrótu. Ponieważ informacje te są ogólnie tajne, stąd potrzeba skrótu, jest to dobra właściwość funkcji skrótu przeznaczonej do użycia w uwierzytelnianiu.

Hash jest ogólnie uważany za „bezpieczny”, jeśli biorąc pod uwagę komunikat M, hash funkcji hash () i wartość skrótu H wytworzoną przez hash (M) o długości w bitach L, żadna z poniższych czynności nie może być wykonana w mniej niż Czas O (2 L ):

  • Biorąc pod uwagę hash () i H, produkujemy M. (odporność na preimage)
  • Biorąc pod uwagę hash () i M, produkujemy inny M 2, taki że hash (M 2 ) == H. (słaby opór zderzenia)
  • Biorąc pod uwagę hash (), produkuj dowolne M 1 i M 2, tak aby hash (M 1 ) == hash (M 2 ). (duża odporność na zderzenia)

Dodatkowo „bezpieczny” skrót musi mieć długość skrótu L taką, że 2 Lnie jest wykonalną liczbą kroków, aby komputer mógł wykonać dany bieżący sprzęt. 32-bitowa liczba całkowita może mieć tylko 2,1 miliarda wartości; podczas gdy atak preimage (znalezienie wiadomości, która generuje określony skrót H) zająłby trochę czasu, nie jest to niemożliwe dla wielu komputerów, szczególnie tych znajdujących się w rękach agencji rządowych, które mają za zadanie łamanie kodów. Ponadto algorytm, który tworzy i przechowuje losowe wiadomości i ich skróty, według prawdopodobieństwa, miałby 50% szans na znalezienie duplikatu każdej nowej wiadomości po wypróbowaniu tylko 77 000 wiadomości i miałby 75% szansy na trafienie zduplikowane już po 110 000. Nawet skróty 64-bitowe nadal mają 50% szans na zderzenie po wypróbowaniu zaledwie około 5 miliardów wartości. Taka jest siła urodzinowego ataku na małe hasze. Natomiastliczby decylionowe (1,5 * 10 34 ).

Większość zademonstrowanych ataków na kryptograficzne skróty to ataki kolizyjne, które wykazały zdolność do generowania kolidujących wiadomości w czasie krótszym niż 2 l (większość nadal była czasem wykładniczym, ale zmniejszenie wykładnika o połowę jest znaczącym zmniejszeniem złożoności, ponieważ powoduje 256-bitowy skrót tak łatwy do rozwiązania jak 128-bitowy, 128-bitowy tak łatwy do rozwiązania jak 64-bitowy itp.).

Oprócz małego rozmiaru skrótu, innymi czynnikami, które mogą sprawić, że skrót jest wyraźnie niepewny, są:

Niska praca - skrót zaprojektowany do użycia przez tablicę skrótów lub do innych celów typu „suma kontrolna” jest zwykle zaprojektowany tak, aby był niedrogi obliczeniowo. To znacznie ułatwia atak z użyciem siły.

„Sticky State” - Funkcja skrótu jest podatna na wzorce danych wejściowych, w których bieżąca wartość skrótu wszystkich dotychczasowych danych nie zmienia się, gdy otrzyma się określony dodatkowy bajt danych wejściowych. Posiadanie „stanu lepkiego” ułatwia znajdowanie kolizji, ponieważ po zidentyfikowaniu wiadomości, która generuje skrót „stanu lepkiego”, generowanie innych wiadomości o tym samym haszu jest trywialne przez dołączanie bajtów wejściowych, które utrzymują skrót w jego „lepkim stanie” „.

Dyfuzja - każdy bajt wejściowy wiadomości powinien być rozdzielony między bajty wartości skrótu w równie złożony sposób. Niektóre funkcje skrótu powodują przewidywalne zmiany w niektórych bitach skrótu. To znowu sprawia, że ​​tworzenie kolizji jest trywialne; biorąc pod uwagę komunikat, który tworzy skrót, można łatwo utworzyć kolizje, wprowadzając do komunikatu nowe wartości, które wpływają tylko na bity zmieniające się w przewidywalny sposób.


0

Użyj właściwego algorytmu dla danego zadania.

CRC są używane do wykrywania / korekcji błędów.

Skrypty wiadomości kryptograficznych, takie jak SHA2, są wykorzystywane jako element konstrukcyjny dla konstrukcji kryptograficznych (podpisy cyfrowe, adresy MAC, funkcje wyprowadzania kluczy / haszowania haseł) oraz protokołów bezpieczeństwa.

W tablicach skrótów / słownikach / mapach używaj SipHash .

To, co nazywacie niezabezpieczonymi algorytmami mieszania, nie powinno być używane w tabelach skrótów , co potwierdzają następujące wpisy CVE: CVE-2003-0364, CVE-2011-4461, CVE-2011-4838, CVE-2011-4885, CVE-2011- 4462, CVE-2011-4815, CVE-2012-0840, CVE-2012-5371 , CVE-2012-5374, CVE-2012-5375

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.