Kiedy należy używać CRC do wykrywania błędów w porównaniu z nowszymi funkcjami mieszającymi, takimi jak MD5 lub SHA1? Czy to pierwsze jest łatwiejsze do wdrożenia na sprzęcie wbudowanym?
Odpowiedzi:
CRC działa dobrze w przypadku wykrywania przypadkowych błędów w danych, które mogą wystąpić, na przykład z powodu zakłóceń sieciowych, szumów linii, zniekształceń itp.
CRC jest obliczeniowo znacznie mniej skomplikowane niż MD5 lub SHA1. Używanie funkcji skrótu, takiej jak MD5, jest prawdopodobnie przesadą w przypadku wykrywania przypadkowych błędów. Jednak użycie CRC do dowolnego rodzaju kontroli bezpieczeństwa byłoby znacznie mniej bezpieczne niż bardziej złożona funkcja mieszająca, taka jak MD5.
I tak, CRC jest znacznie łatwiejsze do wdrożenia na sprzęcie wbudowanym, możesz nawet uzyskać różne pakiety rozwiązań do tego na układach scalonych.
MD5, SHA-1należy go również unikać, SHA-2zalecany jest pewien wariant .
CRC jest zaprojektowany przed niezamierzonymi zmianami danych. Oznacza to, że jest dobry do wykrywania niezamierzonych błędów, ale będzie bezużyteczny jako sposób na upewnienie się, że dane nie zostały złośliwie przetworzone.
Zobacz także to .
Znalazłem badanie, które pokazuje, jak nieodpowiednie są skróty CRC dla tabel skrótów . Wyjaśnia również rzeczywistą charakterystykę algorytmu. Badanie obejmuje również ocenę innych algorytmów wyznaczania wartości skrótu i jest dobrym źródłem informacji.
Odpowiedni wniosek dotyczący CRC dla hashów:
CRC32 nigdy nie był przeznaczony do użytku z tablicą mieszającą. Naprawdę nie ma dobrego powodu, aby używać go w tym celu i radzę tego unikać. Decydując się na użycie CRC32, ważne jest, aby użyć bitów skrótu od końca przeciwnego do tego, w którym podawane są oktety klucza. Który koniec zależy od konkretnej implementacji CRC32. Nie traktuj CRC32 jako funkcji skrótu „czarnej skrzynki” i nie używaj jej jako skrótu ogólnego przeznaczenia. Pamiętaj, aby przetestować każdą aplikację pod kątem przydatności.
AKTUALIZACJA
Wygląda na to, że witryna nie działa. Archiwum internetowego ma kopię chociaż.
Uruchomiłem każdą linię tego kodu PHP w pętli 1.000.000. Wyniki są w komentarzach (#).
hash('crc32', 'The quick brown fox jumped over the lazy dog.');# 750ms 8 chars
hash('crc32b','The quick brown fox jumped over the lazy dog.');# 700ms 8 chars
hash('md5', 'The quick brown fox jumped over the lazy dog.');# 770ms 32 chars
hash('sha1', 'The quick brown fox jumped over the lazy dog.');# 880ms 40 chars
hash('sha256','The quick brown fox jumped over the lazy dog.');# 1490ms 64 chars
hash('sha384','The quick brown fox jumped over the lazy dog.');# 1830ms 96 chars
hash('sha512','The quick brown fox jumped over the lazy dog.');# 1870ms 128 chars
Mój wniosek:
Użyj "sha256" (lub nowszego), gdy potrzebujesz dodatkowej warstwy bezpieczeństwa.
Nie używaj „md5” ani „sha1”, ponieważ mają:
"The quick brown fox jumped over the lazy dog." ), zobaczysz, o ile szybsze jest CRC niż MD5.
Aby uzyskać informacje o CRC na temat implementacji, szybkości i niezawodności, zobacz Bezbolesny przewodnik po algorytmach wykrywania błędów CRC . Ma wszystko na CRC.
Chyba że ktoś spróbuje złośliwie zmodyfikować twoje dane i ukryć zmianę CRC jest wystarczające. Po prostu użyj „dobrego” (standardowego) wielomianu.
Wszystko zależy od Twoich wymagań i oczekiwań.
Oto krótkie krótkie różnice między tymi algorytmami funkcji skrótu :
jest kryptograficznym algorytmem mieszania,
generuje 160-bitową (20-bajtową) wartość skrótu zwaną skrótem wiadomości
jest to hash kryptograficzny i od 2005 roku nie jest już uważany za bezpieczny,
może służyć do szyfrowania,
pierwszy raz opublikowany w 1993 roku (jako SHA-0), a następnie 1995 jako SHA-1,
serie: SHA-0, SHA-1, SHA-2, SHA-3,
Podsumowując, przy użyciu SHA-1 nie jest już uważane za bezpieczne przeciwko dobrze finansowanych przeciwników, bo w 2005 roku, znaleziono kryptoanalitycy ataki na SHA-1, co sugeruje, że być może nie wystarczająco bezpieczne dla ciągłego użytkowania Schneier . NIST USA zaleca, aby agencje federalne zaprzestały używania SHA1-1 do zastosowań wymagających odporności na kolizje i muszą używać SHA-2 po NIST 2010 .
Dlatego jeśli szukasz prostego i szybkiego rozwiązania do sprawdzania integralności plików (pod kątem uszkodzenia) lub do prostych celów buforowania pod względem wydajności, możesz rozważyć CRC-32, jako haszowanie, które możesz rozważyć. MD5, jeśli jednak tworzysz profesjonalną aplikację (która powinna być bezpieczna i spójna), aby uniknąć prawdopodobieństwa kolizji - użyj SHA-2 i nowszych (takich jak SHA-3).
Kilka prostych testów porównawczych w PHP:
# Testing static text.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32("foo");'
real 0m0.845s
user 0m0.830s
sys 0m0.008s
$ time php -r 'for ($i=0;$i<1000000;$i++) md5("foo");'
real 0m1.103s
user 0m1.089s
sys 0m0.009s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1("foo");'
real 0m1.132s
user 0m1.116s
sys 0m0.010s
# Testing random number.
$ time php -r 'for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'
real 0m1.754s
user 0m1.735s
sys 0m0.012s\
$ time php -r 'for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'
real 0m2.065s
user 0m2.042s
sys 0m0.015s
$ time php -r 'for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'
real 0m2.050s
user 0m2.021s
sys 0m0.015s
Związane z:
Nie mówisz, co próbujesz chronić.
CRC jest często używany w systemach wbudowanych jako kontrola przed przypadkowym uszkodzeniem danych, w przeciwieństwie do zapobiegania złośliwej modyfikacji systemu. Przykładami miejsc, w których CRC może być przydatna, jest walidacja obrazu EPROM podczas inicjalizacji systemu w celu ochrony przed uszkodzeniem oprogramowania układowego. Program ładujący system obliczy CRC dla kodu aplikacji i porówna go z zapisaną wartością przed zezwoleniem na uruchomienie kodu. Chroni to przed możliwością przypadkowego uszkodzenia programu lub niepowodzeniem pobierania.
CRC może być również używany w podobny sposób do ochrony danych konfiguracyjnych przechowywanych w pamięci FLASH lub EEPROM. Jeśli CRC jest niepoprawne, dane można oznaczyć jako nieważne i użyć domyślnego lub zapasowego zestawu danych. CRC może być nieważne z powodu awarii urządzenia lub jeśli użytkownik odłączył zasilanie podczas aktualizacji magazynu danych konfiguracyjnych.
Pojawiły się komentarze, że hash zapewnia większe prawdopodobieństwo wykrycia uszkodzenia niż CRC z wieloma błędami bitów. To prawda, a decyzja, czy użyć 16- lub 32-bitowego CRC, będzie zależeć od konsekwencji bezpieczeństwa użycia uszkodzonego bloku danych i czy można uzasadnić szansę 1 na 2 ^ 16 lub 2 ^ 32 blok danych został nieprawidłowo zadeklarowany jako ważny.
Wiele urządzeń ma wbudowany generator CRC dla standardowych algorytmów. Seria MSP430F5X z Teksasu posiada sprzętową implementację standardu CRC-CCITT.
Używaj CRC tylko wtedy, gdy zasoby obliczeniowe są bardzo ograniczone (np. Niektóre środowiska osadzone) lub musisz przechowywać / transportować wiele wartości wyjściowych, a przestrzeń / przepustowość jest niewielka (ponieważ CRC są zwykle 32-bitowe, a wyjście MD5 jest 128-bitowe, SHA1 160 bit i inne warianty SHA do 512 bitów).
Nigdy nie używaj CRC do kontroli bezpieczeństwa, ponieważ CRC jest bardzo łatwe do „sfałszowania”.
Nawet w przypadku wykrycia przypadkowych błędów (zamiast wykrywania złośliwych zmian) skróty są lepsze niż zwykłe CRC. Częściowo z powodu prostego sposobu obliczania CRC (a częściowo dlatego, że wartości CRC są zwykle krótsze niż typowe wartości wyjściowe skrótu, więc mają znacznie mniejszy zakres możliwych wartości), jest znacznie bardziej prawdopodobne, że w sytuacji, gdy wystąpią dwa lub więcej błędów jeden błąd maskuje inny, więc mimo dwóch błędów otrzymujesz ten sam CRC.
W skrócie: jeśli nie masz powodu, aby nie używać przyzwoitego algorytmu mieszającego, unikaj prostych CRC.
Niedawno natknąłem się na zastosowanie CRC, które było sprytne. Autor narzędzia do identyfikacji i usuwania duplikatów plików jdupe (ten sam autor popularnego narzędzia exif jhead) używa go podczas pierwszego przejścia przez pliki. CRC jest obliczane na pierwszych 32K każdego pliku, aby oznaczyć pliki, które wydają się takie same, również pliki muszą mieć ten sam rozmiar. Pliki te są dodawane do listy plików, dla których ma zostać wykonane pełne porównanie binarne. Przyspiesza sprawdzanie dużych plików multimedialnych.
Zacznijmy od podstaw.
W kryptografii algorytm mieszający konwertuje wiele bitów na mniej bitów poprzez operację skrótu. Hashe służą do potwierdzania integralności wiadomości i plików.
Wszystkie algorytmy haszujące generują kolizje. Kolizja ma miejsce, gdy kilka kombinacji wielobitowych daje taką samą mniejszą liczbę bitów na wyjściu. Siła kryptograficzna algorytmu haszującego jest definiowana przez niezdolność osoby do określenia, jakie będą dane wyjściowe dla danego wejścia, ponieważ gdyby mogli skonstruować plik z hashem pasującym do legalnego pliku i naruszyć zakładaną integralność systemu. Różnica między CRC32 i MD5 polega na tym, że MD5 generuje większy hash, który jest trudniejszy do przewidzenia.
Kiedy chcesz zaimplementować integralność wiadomości - co oznacza, że wiadomość nie została naruszona podczas przesyłania - niemożność przewidywania kolizji jest ważną właściwością. 32-bitowy hash można opisać 4 miliardy różnych komunikatów lub plików za 4 miliardy różnych unikatowych skrótów. Jeśli masz 4 miliardy i 1 pliki, masz gwarancję 1 kolizji. 1 TB przestrzeni bitowej umożliwia miliardy kolizji. Jeśli jestem atakującym i mogę przewidzieć, jaki będzie ten 32-bitowy hash, mogę skonstruować zainfekowany plik, który koliduje z plikiem docelowym; który ma ten sam hash.
Dodatkowo, jeśli wykonuję transmisję z prędkością 10 Mb / s, prawdopodobieństwo uszkodzenia pakietu tylko po to, aby ominąć crc32 i kontynuować do miejsca docelowego i wykonać jest bardzo niskie. Powiedzmy, że przy 10 Mb / s pojawia się 10 błędów \ sekunda . Jeśli zwiększę to do 1 Gb / s, teraz otrzymuję 1000 błędów na sekundę . Jeśli staram się do 1 exabit na sekundę, wówczas wskaźnik błędów wynosi 1000000000 błędów na sekundę . Powiedzmy, że mamy współczynnik kolizji 1 \ 1 000 000błędy transmisji, co oznacza, że 1 na milion błędów transmisji powoduje, że uszkodzone dane przechodzą niewykryte. Przy 10 Mb / s dane o błędach były wysyłane co 100 000 sekund lub mniej więcej raz dziennie. Przy 1 Gbps zdarzało się to raz na 5 minut. Przy 1 eksabitie na sekundę rozmawiamy kilka razy na sekundę.
Jeśli otworzysz Wireshark, zobaczysz, że typowy nagłówek Ethernet ma CRC32, nagłówek IP ma CRC32, a nagłówek TCP ma CRC32, i to dodatkowo do tego, co mogą robić protokoły wyższych warstw; np. IPSEC może używać MD5 lub SHA do sprawdzania integralności oprócz powyższych. Istnieje kilka warstw sprawdzania błędów w typowej komunikacji sieciowej, które NADAL czasami zawodzą przy prędkościach poniżej 10 Mb / s.
Cykliczna kontrola nadmiarowa (CRC) ma kilka popularnych wersji i kilka rzadkich, ale generalnie jest zaprojektowana tak, aby po prostu stwierdzić, kiedy wiadomość lub plik został uszkodzony podczas przesyłania (przerzucanie wielu bitów). Sam CRC32 nie jest dobrym protokołem sprawdzania błędów według dzisiejszych standardów w dużych, skalarnych środowiskach korporacyjnych ze względu na współczynnik kolizji; przeciętny dysk twardy użytkownika może mieć do 100 tys. plików, a udziały plików w firmie mogą mieć dziesiątki milionów. Stosunek przestrzeni mieszania do liczby plików jest po prostu za mały. CRC32 jest obliczeniowo tani do wdrożenia, podczas gdy MD5 nie.
MD5 został zaprojektowany, aby powstrzymać celowe użycie kolizji, aby złośliwy plik wyglądał łagodnie. Jest uważany za niezabezpieczony, ponieważ obszar skrótu został wystarczająco zmapowany, aby umożliwić wystąpienie niektórych ataków, a niektóre kolizje są przewidywalne. SHA1 i SHA2 to nowe dzieciaki w okolicy.
Wielu dostawców zaczyna używać Md5 do weryfikacji plików, ponieważ można z nim szybko tworzyć pliki wielobajtowe lub wielobajtowe i układać je na szczycie ogólnego wykorzystania i obsługi CRC32 przez system operacyjny. Nie zdziw się, jeśli w ciągu następnej dekady systemy plików zaczną używać MD5 do sprawdzania błędów.