Zderzenie CRC32

Próbuję znaleźć kolizję pomiędzy dwoma wiadomościami, która doprowadzi do tego samego hasha CRC. Biorąc pod uwagę, że używam CRC32, czy jest jakiś sposób, aby skrócić listę możliwych wiadomości, które muszę spróbować podczas wykonywania ataku brute force?

Wszelkie linki do stron internetowych z podpowiedziami na ten temat będą pomocne. Mam już algorytm brute force, który to zrobi, ale po prostu zwiększa liczby całkowite i widzi, czy będzie pasował do innych skrótów.

Author: Oleg V. Volkov, 2009-10-04

7 answers

To zależy całkowicie od tego, co rozumiesz przez "wiadomość". Jeśli możesz dołączyć cztery bajty bełkotu do jednej z wiadomości. (Tzn. cztery bajty, które nie mają znaczenia w kontekście wiadomości.) Wtedy staje się trywialne w najprawdziwszym tego słowa znaczeniu.

Myślenie w kategoriach bitów poruszających się przez maszynę stanową CRC32.

CRC32 jest oparty na rejestrze przesunięć sprzężenia zwrotnego galois, każdy bit w swoim stanie zostanie zastąpiony indukcją 32 bitów z danych ładunku. Na indukcja każdego bitu, pozycje wskazane przez wielomian będą wyłączne lub z sekwencją obserwowaną od końca rejestru przesunięcia. Ta sekwencja nie jest zależna od danych wejściowych, dopóki rejestr zmiany nie zostanie wypełniony.

Jako przykład, wyobraźmy sobie, że mamy rejestr przesunięcia wypełniony stanem początkowym 10101110, wielomianem 10000011 i wypełnionym nieznanymi bitami, X.

Polynomial *     **  |feedback (End of SR.)
State      10101110     0
State      X1010111     1
State      XX101000     0
State      XXX10100     0
State      XXXX1010     0
State      XXXXX101     1
State      XXXXXX01     1
State      XXXXXXX1     1
State      XXXXXXXX     0

Informacja zwrotna nie jest w kategoriach X, dopóki SR nie zostanie wypełniona! Aby więc wygenerować wiadomość z określoną sumą kontrolną, bierzesz nową wiadomość, generujesz CRC i ustalasz, że to kolejne 32 bity sprzężenia zwrotnego. Można to zrobić w 32 krokach funkcji CRC. Następnie należy obliczyć wpływ, jaki ta informacja zwrotna ma na zawartość rejestru zmian.

Skrótem do zrobienia tego jest umieszczenie wiadomości z czterema zerowymi bajtami, a następnie spojrzenie na sumę kontrolną. (Suma kontrolna to stan SR na końcu, który jeśli jest wypełniony czterema zerowymi bajtami to wpływ sprzężenie zwrotne i puste bajty.)

Exclusive lub, że wpływa z wartości sumy kontrolnej chcesz, zastąpić przyczepę czterech bajtów z tej wartości obliczeniowej i zregenerować sumę kontrolną. Możesz to zrobić za pomocą dowolnego programu, który generuje CRC32, edytora szesnastkowego i kalkulatora, który może obsługiwać szesnastkowy.

Jeśli chcesz wygenerować dwie wiadomości, które mają pełny sens i nie zawierają końcowych śmieci, sprawy stają się trochę trudniejsze. Określ liczbę sekcji, które możesz napisać możliwe alternatywy, o dokładnie tej samej długości.

Używając prozy Angielskiej jako przykładu. "Myślę, że to może zadziałać" oraz "Wierzę w takie podejście" Mają zasadniczo podobne znaczenia i dokładnie taką samą długość.

Identyfikacja wystarczającej liczby przykładów w wiadomości jest trudnym bitem (chyba że chcesz oszukiwać z białymi spacjami!) CRC 32 jest liniowy, pod warunkiem, że dane mają poprawne przesunięcie w obrębie wiadomości. Więc CRC([messagea][padding])^CRC ([padding] [messageb])=CRC ([messagea] [messageb]) Istnieją pewne zastrzeżenia z wyrównaniem słów, z którymi musisz sobie poradzić, jako ogólna wskazówka, chcesz rozszerzyć fragmenty na "stałe" części wiadomości. Zasadniczo chcemy mieć alternatywy dla N * 1,5, gdzie n jest wielkością CRC.

Możesz teraz obliczyć CRC, jaki ma wiadomość szkieletowa, wrażenie, że każdy alternatywny fragment miałby na niej, a następnie sporządzić tabela porównująca wpływ, jaki miałaby każda alternatywa dla każdego fragmentu. Następnie musisz wybrać alternatywy, które zmodyfikują szkieletowy CRC, aby dopasować CRC, który chcesz. Ten problem jest rzeczywiście dość zabawne do rozwiązania, po pierwsze znaleźć wszelkie alternatywy, które jednoznacznie zmodyfikować trochę, jeśli ten bit musi zmienić dla CRC, wybierz tę alternatywę i złożyć to wpływ na CRC, a następnie przejść ponownie. To powinno zmniejszyć przestrzeń rozwiązania, które następnie trzeba przeszukiwać.

To dość trudne do zakodowania, ale generowałoby to kolizje w bardzo krótkim czasie.

 24
Author: scruffy_brit,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-11-24 14:27:00

Poza wadą mojego rachunku, prawdopodobieństwo nie znalezienia jednej kolizji po N próbach jest przybliżone w poniższej tabeli:

  N      Probability
-------  -----------
 50,000  74.7%
 77,000  50.1%
 78,000  49.2%
102,000  29.8%
110,000  24.5%
128,000  14.8%
150,000   7.3%
200,000   0.95%

Innymi słowy, prawdopodobieństwo obliczenia ponad 200 000 wartości CRC32 przed znalezieniem duplikatu jest mniejsze niż 1%, lub prawdopodobieństwo znalezienia duplikatu przed 102 000 prób wynosi 70,2%
BTW jest to niezwykłe, ponieważ prawdopodobieństwo znalezienia jednej kolizji na, powiedzmy, Bardzo 200,000 TH próba jest nadal w porządku 1/1000th z 1% ((4M - 200,0000) / 4M), ale prawdopodobnie znaleźć jedną kolizję przed 200,000 TH próba jest quasi pewność (dobrze, powyżej 99% w każdym razie). pokazuje to zainteresowanie utrzymaniem bazy danych CRC obliczonych do tej pory.

Z pewnością moglibyśmy poświęcić trochę czasu na studiowanie algorytmu CRC32 i jego podstawowej matematyki, próbując znaleźć wiadomości bardziej prawdopodobne, aby stworzyć CRC32 kolizje , ale stosunkowo niewielka liczba naprawdę losowych prób potrzebnych do znalezienia co najmniej jednej kolizji z quasi pewnością, sprawia, że tego rodzaju podejście do kryptoanalizy nie jest warte wysiłku. Na przykład zakładając, że możemy odkryć sposób na wybranie wiadomości, które są 10 razy bardziej narażone na kolizję, nadal będziemy musieli spróbować w kolejności 63 000 razy, zanim osiągniemy 99% szanse na co najmniej jedną kolizję (lepsze niż 200 000, ale nadal wymagające mniej więcej ten sam typ aplikacji.)
Jedyną rzeczą, którą możemy rozważyć, w tym obszarze, jest unikanie wiadomości krótszych niż 4 bajty (czytałem gdzieś, że CRC32 był bijektywny w tej przestrzeni wiadomości), oraz unikanie wiadomości, które są zbyt podobne (tzn. różnią się tylko jednym lub dwoma znakami), ponieważ po pierwotnym celu CRC32 jest wykrywanie (i ewentualnie Auto-poprawienie) tak małych różnic w wiadomościach.

Dlatego wydaje się, że trudność przyporządkowania polega nie tyle na znalezieniu sposobów obliczania CRC32 z dużą prędkością (choć nie powinniśmy być zbyt powolni), ale raczej na zarządzaniu szybko przeszukiwalną bazą danych do 200 000 wiadomości (lub wiadomość "klucz", więcej na ten temat poniżej) i powiązaną z nią wartością CRC32.

Kilka pomysłów na realizację tego wszystkiego

  • potrzebujesz prostej biblioteki ISAM, lub lepiej formalnego interfejsu DBMS, takiego jak MySql lub nawet SqlLite.
  • używając pseudo generator liczb losowych (PRNG), aby wygenerować wiadomości, możemy zapisać klucze wiadomości (tzn. cokolwiek podamy PRNG do wytworzenia danej wiadomości), zamiast przechowywać całą wiadomość . To uczyniłoby wstawianie i przeszukiwanie bazy danych bardziej efektywnym, ryzykując błędne wybranie PRNG (a raczej generatora liczb losowych pm), tzn. takiego, który generowałby (na początku) wiadomości, które są w jakiś sposób mniej narażone na zderzenie CRC32...
  • jest prawdopodobnie lepiej pracować partiami, tzn. produkować powiedzmy 1000 nowych CRC, a następnie sprawdzać kolizje i przechowywać je, zamiast robić to wszystko dla jednego CRC na raz. Jest to szczególnie prawdziwe, jeśli używamy off-the-shelf DBMS
 15
Author: mjv,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-10-05 00:28:18

Właśnie wczoraj było to pytanie tutaj NA więc, kilka wskazówek tam wymienionych może Ci pomóc.

 1
Author: fvu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:33:39

Brute force potrzebujesz około sqrt(6N) wiadomości o losowej długości dla hasha o rozmiarze N, aby uzyskać 95% prawdopodobieństwo kolizji. Np. CRC32, N = 2^32, potrzebujesz około 160 000 wiadomości

 1
Author: user1087245,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-12-08 07:28:18

Zakładam, że masz na myśli "wiadomość" zamiast "klucz".

Jeśli możesz wybrać oba "klucze", to brute-force i tak byłoby raczej szybkie ze względu na paradoks urodzinowy. Wybierz losowe wiadomości, Oblicz ich CRC, zapamiętaj je wszystkie i powiązane CRC, a każdy nowy ma coraz więcej szans na zderzenie z istniejącym, gdy się kumulują. Szczerze mówiąc, oczekuję, że takie podejście będzie szybsze na nowoczesnym komputerze niż szukanie znanych podejść do stworzenia CRC32 zderzenie.

 0
Author: Pascal Cuoq,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-10-04 09:06:08

Uważam, że CRC są liniowe, więc jeśli zmodyfikujesz (na miejscu, bez zmiany długości) dwie różne części pliku, różnice w CRC powinny być połączone ze sobą.

-- poprawka: to nie wydaje się być takie proste. Jednak nadal jest to rodzaj taktyki, którą podjąłbym próbując skonstruować kolizję. musisz przestrzegać matematyki bardziej szczegółowo, niż jestem skłonny zrobić dziś wieczorem...

 0
Author: comingstorm,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-10-04 09:24:35

Spoof robi dokładnie to. Nie wymaga brutalnej siły.

 0
Author: Mark Adler,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-05-17 16:50:53