Antworten:
CRC eignet sich gut zum Erkennen zufälliger Fehler in Daten, die beispielsweise aufgrund von Netzwerkstörungen, Leitungsrauschen, Verzerrungen usw. auftreten können.
CRC ist rechnerisch viel weniger komplex als MD5 oder SHA1. Die Verwendung einer Hash-Funktion wie MD5 ist wahrscheinlich ein Overkill für die zufällige Fehlererkennung. Die Verwendung von CRC für jede Art von Sicherheitsüberprüfung wäre jedoch viel weniger sicher als eine komplexere Hashing-Funktion wie MD5.
Und ja, CRC ist auf eingebetteter Hardware viel einfacher zu implementieren. Auf IC können Sie sogar verschiedene Paketlösungen dafür erhalten.
MD5, SHA-1sollte auch vermieden werden, eine Variante von SHA-2wird empfohlen.
CRC ist gegen unbeabsichtigte Änderungen der Daten ausgelegt. Das heißt, es ist gut, um unbeabsichtigte Fehler zu erkennen, aber es ist nutzlos, um sicherzustellen, dass Daten nicht böswillig behandelt wurden.
Siehe auch dies .
Ich habe eine Studie gefunden, die zeigt, wie unangemessen CRC-Hashes für Hash-Tabellen sind . Außerdem werden die tatsächlichen Eigenschaften des Algorithmus erläutert. Die Studie umfasst auch die Bewertung anderer Hash-Algorithmen und ist eine gute Referenz.
Die relevante Schlussfolgerung zu CRC für Hashes:
CRC32 war niemals für die Verwendung in Hash-Tabellen vorgesehen. Es gibt wirklich keinen guten Grund, es für diesen Zweck zu verwenden, und ich empfehle Ihnen, dies zu vermeiden. Wenn Sie sich für CRC32 entscheiden, ist es wichtig, dass Sie die Hash-Bits von dem Ende verwenden, das dem Ende entgegengesetzt ist, in das die Schlüsseloktette eingespeist werden. Welches Ende dies ist, hängt von der spezifischen CRC32-Implementierung ab. Behandeln Sie CRC32 nicht als "Black Box" -Hash-Funktion und verwenden Sie es nicht als Allzweck-Hash. Stellen Sie sicher, dass Sie jede Anwendung auf ihre Eignung prüfen.
AKTUALISIEREN
Es scheint, dass die Seite nicht verfügbar ist. Das Internetarchiv hat jedoch eine Kopie .
Ich habe jede Zeile dieses PHP-Codes in einer 1.000.000-Schleife ausgeführt. Die Ergebnisse sind in Kommentaren (#) angegeben.
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
Meine Schlussfolgerung:
Verwenden Sie "sha256" (oder höher), wenn Sie eine zusätzliche Sicherheitsschicht benötigen.
Verwenden Sie nicht "md5" oder "sha1", weil sie:
"The quick brown fox jumped over the lazy dog."), sehen Sie, wie viel schneller CRC als MD5 ist.
CRC-Informationen zu Implementierung, Geschwindigkeit und Zuverlässigkeit finden Sie unter Eine schmerzlose Anleitung zu CRC-Fehlererkennungsalgorithmen . Es hat alles auf CRCs.
Es sei denn, jemand wird versuchen, Ihre Daten böswillig zu ändern und die Änderung zu verbergen. CRC ist ausreichend. Verwenden Sie einfach ein "gutes" (Standard-) Polinom.
Es hängt alles von Ihren Anforderungen und Erwartungen ab.
Hier sind kurze Unterschiede zwischen diesen Hash-Funktionsalgorithmen :
ist ein kryptografischer Hash-Algorithmus,
Erzeugt einen 160-Bit-Hashwert (20 Byte), der als Message Digest bezeichnet wird
Es ist ein kryptografischer Hash und wird seit 2005 nicht mehr als sicher angesehen.
kann für Verschlüsselungszwecke verwendet werden,
zuerst 1993 veröffentlicht (als SHA-0), dann 1995 als SHA-1,
Serie: SHA-0, SHA-1, SHA-2, SHA-3,
Zusammengefasst mit SHA-1 nicht mehr als sicher betrachtet gegen finanziell gut ausgestatteten Gegner, weil im Jahr 2005 Kryptanalytiker Angriffe auf SHA-1 , die es für die laufende Nutzung nicht sicher genug , um möglicherweise schon sagt gefunden sein Schneier . US NIST rät den Bundesbehörden, SHA1-1 nicht mehr für Anwendungen zu verwenden, die Kollisionsfestigkeit erfordern, und SHA-2 nach NIST 2010 zu verwenden .
Wenn Sie nach einer einfachen und schnellen Lösung suchen, um die Integrität einer Datei (gegen Beschädigung) zu überprüfen, oder nach einfachen Caching-Zwecken in Bezug auf die Leistung, können Sie CRC-32 für Hashing in Betracht ziehen, das Sie möglicherweise verwenden möchten MD5 Wenn Sie jedoch eine professionelle Anwendung entwickeln (die sicher und konsistent sein sollte), um Kollisionswahrscheinlichkeiten zu vermeiden, verwenden Sie SHA-2 und höher (z. B. SHA-3).
Einige einfache Benchmark-Tests in 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
Verbunden:
Sie sagen nicht, was Sie schützen wollen.
Ein CRC wird in eingebetteten Systemen häufig zur Überprüfung auf versehentliche Datenbeschädigung verwendet, anstatt böswillige Systemänderungen zu verhindern. Beispiele für Orte, an denen ein CRC nützlich sein kann, sind die Überprüfung eines EPROM-Images während der Systeminitialisierung, um eine Beschädigung der Firmware zu vermeiden. Der System-Bootloader berechnet den CRC für den Anwendungscode und vergleicht ihn mit dem gespeicherten Wert, bevor der Code ausgeführt werden kann. Dies schützt vor der Möglichkeit einer versehentlichen Programmbeschädigung oder eines fehlgeschlagenen Downloads.
Ein CRC kann auf ähnliche Weise auch zum Schutz der in FLASH oder EEPROM gespeicherten Konfigurationsdaten verwendet werden. Wenn die CRC nicht korrekt ist, können die Daten als ungültig gekennzeichnet und ein Standard- oder Sicherungsdatensatz verwendet werden. Der CRC ist möglicherweise aufgrund eines Gerätefehlers oder wenn der Benutzer während einer Aktualisierung des Konfigurationsdatenspeichers die Stromversorgung unterbrochen hat, ungültig.
Es gab Kommentare, dass ein Hash eine größere Wahrscheinlichkeit für die Erkennung von Beschädigungen bietet als ein CRC mit Mehrbitfehlern. Dies ist richtig, und die Entscheidung, ob ein 16- oder 32-Bit-CRC verwendet werden soll oder nicht, hängt von den Sicherheitsfolgen eines verwendeten beschädigten Datenblocks ab und davon, ob Sie die 1: 2 ^ 16- oder 2 ^ 32-Chance von a rechtfertigen können Datenblock wird fälschlicherweise für gültig erklärt.
Viele Geräte verfügen über einen eingebauten CRC-Generator für Standardalgorithmen. Die MSP430F5X-Serie aus Texas verfügt über eine Hardware-Implementierung des CRC-CCITT-Standards.
Verwenden Sie CRC nur, wenn die Rechenressourcen sehr knapp sind (dh einige Einbettungsumgebungen) oder wenn Sie viele Ausgabewerte speichern / transportieren müssen und Speicherplatz / Bandbreite knapp sind (da CRCs normalerweise 32-Bit sind, wenn eine MD5-Ausgabe 128-Bit ist, SHA1 160 Bit und andere SHA-Varianten bis zu 512 Bit).
Verwenden Sie CRC niemals für Sicherheitsüberprüfungen, da CRC sehr leicht zu "fälschen" ist.
Selbst für die versehentliche Fehlererkennung (und nicht für die Erkennung böswilliger Änderungen) sind Hashes besser als ein einfacher CRC. Teilweise aufgrund der einfachen Art und Weise, wie eine CRC berechnet wird (und teilweise, weil CRC-Werte normalerweise kürzer als herkömmliche Hash-Ausgaben sind und daher einen viel kleineren Bereich möglicher Werte aufweisen), ist es viel wahrscheinlicher, dass in einer Situation, in der zwei oder mehr Fehler vorliegen Ein Fehler maskiert einen anderen, sodass Sie trotz zweier Fehler denselben CRC erhalten.
Kurz gesagt: Vermeiden Sie einfache CRCs, es sei denn, Sie haben Grund, keinen anständigen Hash-Algorithmus zu verwenden.
Ich bin kürzlich auf eine Verwendung von CRC gestoßen, die klug war. Der Autor des Tools zum Identifizieren und Entfernen von jdupe-Dateiduplikationen (derselbe Autor des beliebten exif-Tools jhead) verwendet es beim ersten Durchlaufen der Dateien. Auf den ersten 32 KB jeder Datei wird eine CRC berechnet, um Dateien zu markieren, die gleich zu sein scheinen. Außerdem müssen die Dateien dieselbe Größe haben. Diese Dateien werden zu einer Liste von Dateien hinzugefügt, für die ein vollständiger binärer Vergleich durchgeführt werden soll. Es beschleunigt das Überprüfen großer Mediendateien.
Beginnen wir mit den Grundlagen.
In der Kryptographie konvertiert ein Hashing-Algorithmus durch eine Digest-Operation viele Bits in weniger Bits. Hashes werden verwendet, um die Integrität von Nachrichten und Dateien zu bestätigen.
Alle Hashing-Algorithmen erzeugen Kollisionen.Eine Kollision liegt vor, wenn mehrere Vielbitkombinationen dieselbe weniger Bitausgabe erzeugen. Die kryptografische Stärke eines Hashing-Algorithmus wird durch die Unfähigkeit einer Person definiert, zu bestimmen, wie die Ausgabe für eine bestimmte Eingabe aussehen wird, da sie, wenn sie könnte, eine Datei mit einem Hash erstellen könnte, der einer legitimen Datei entspricht, und die angenommene Integrität gefährden könnte vom System. Der Unterschied zwischen CRC32 und MD5 besteht darin, dass MD5 einen größeren Hash generiert, der schwerer vorherzusagen ist.
Wenn Sie die Nachrichtenintegrität implementieren möchten, dh die Nachricht wurde während der Übertragung nicht manipuliert, ist die Unfähigkeit, Kollisionen vorherzusagen, eine wichtige Eigenschaft. Ein 32-Bit-Hash kann 4 Milliarden verschiedene Nachrichten beschreiben oder Dateien mit 4 Milliarden verschiedenen eindeutigen Hashes beschreiben. Wenn Sie 4 Milliarden und 1 Dateien haben, ist 1 Kollision garantiert. 1 TB Bitspace bietet die Möglichkeit für Milliarden von Kollisionen. Wenn ich ein Angreifer bin und vorhersagen kann, wie dieser 32-Bit-Hash aussehen wird, kann ich eine infizierte Datei erstellen, die mit der Zieldatei kollidiert. das hat den gleichen Hash.
Wenn ich eine 10-Mbit / s-Übertragung durchführe, ist die Wahrscheinlichkeit, dass ein Paket genau richtig beschädigt wird, um crc32 zu umgehen und weiter zum Ziel zu fahren und auszuführen, sehr gering. Nehmen wir an, bei 10 MBit / s erhalte ich 10 Fehler pro Sekunde . Wenn ich das auf 1 Gbit / s erhöhe, erhalte ich jetzt 1.000 Fehler pro Sekunde . Wenn ich bis zu 1 Exabit pro Sekunde ramme, habe ich eine Fehlerrate von 1.000.000.000 Fehlern pro Sekunde . Angenommen, wir haben eine Kollisionsrate von 1 \ 1,000,000 Übertragungsfehlern. Das bedeutet, dass 1 von 1 Million Übertragungsfehlern dazu führt, dass beschädigte Daten unentdeckt durchkommen. Bei 10 MBit / s werden alle 100.000 Sekunden oder etwa einmal am Tag Fehlerdaten gesendet. Bei 1 Gbit / s würde es einmal alle 5 Minuten passieren. Bei 1 Exabit pro Sekunde sprechen wir mehrmals pro Sekunde.
Wenn Sie Wireshark öffnen, sehen Sie, dass Ihr typischer Ethernet-Header einen CRC32 hat, Ihr IP-Header einen CRC32 hat und Ihr TCP-Header einen CRC32 hat. Beispielsweise verwendet IPSEC möglicherweise zusätzlich zu den oben genannten Informationen MD5 oder SHA zur Integritätsprüfung. In der typischen Netzwerkkommunikation gibt es mehrere Ebenen der Fehlerprüfung, die immer noch ab und zu bei Geschwindigkeiten unter 10 MBit / s fehlerhaft sind.
Cyclic Redundancy Check (CRC) hat mehrere gängige und einige ungewöhnliche Versionen, dient jedoch im Allgemeinen dazu, nur festzustellen, wann eine Nachricht oder Datei während der Übertragung beschädigt wurde (mehrere Bits werden umgedreht). CRC32 an sich ist aufgrund der Kollisionsrate nach heutigen Standards in großen, skalaren Unternehmensumgebungen kein sehr gutes Fehlerprüfprotokoll. Die durchschnittliche Festplatte eines Benutzers kann über 100.000 Dateien enthalten, und Dateifreigaben in einem Unternehmen können mehrere zehn Millionen Dateien enthalten. Das Verhältnis von Hash-Speicherplatz zu Anzahl der Dateien ist einfach zu niedrig. CRC32 ist rechnerisch billig zu implementieren, MD5 nicht.
MD5 wurde entwickelt, um die absichtliche Verwendung von Kollisionen zu stoppen, damit eine schädliche Datei harmlos aussieht. Es wird als unsicher angesehen, da der Hashspace ausreichend zugeordnet wurde, um einige Angriffe zu ermöglichen, und einige Kollisionen vorhersehbar sind. SHA1 und SHA2 sind die neuen Kinder auf dem Block.
Für die Dateiverifizierung wird Md5 zunehmend von vielen Anbietern verwendet, da Sie damit schnell Multigigabyte- oder Multiterrabyte-Dateien erstellen und diese zusätzlich zur Verwendung und Unterstützung von CRC32 durch das allgemeine Betriebssystem stapeln können. Seien Sie nicht überrascht, wenn Dateisysteme innerhalb des nächsten Jahrzehnts MD5 zur Fehlerprüfung verwenden.