CRC-32 Rechner - Prüfsumme für Text, Hex und Dateien

CRC-32 wird überall dort eingesetzt, wo eine billige und nahezu sichere Prüfung gegen zufällige Beschädigung mehr wert ist als ein Sicherheitsgarantie. Jedes ZIP-Archiv speichert pro Eintrag eine im Zentralverzeichnis, und unzip prüft sie beim Entpacken, sodass eine abgeschnittene oder von Bitfehlern betroffene Datei gemeldet wird, statt stillschweigend Unsinn zu erzeugen. gzip und zlib hängen einen CRC-32 an ihren komprimierten Strom an, weshalb eine beschädigte .gz-Datei einen Prüfsummenfehler meldet und keine unerklärlichen Dekompressionsfehler. PNG speichert in jedem einzelnen Chunk eine CRC-32, sowohl um jeden Block einzeln zu prüfen als auch um den Dekodierer beim ersten defekten Chunk anzuhalten. MPEG-2-Transportströme führen einen pro Paket, und die Frame Check Sequence von Ethernet ist ein CRC-32, den die Netzwerkkarte normalerweise in Hardware für jedes Frame berechnet, das einen Switch durchquert. In allen diesen Fällen ist das Bedrohungsmodell dasselbe: Rauschen, Alterung, unvollständige Schreibvorgänge und nicht übereinstimmende Versionen, nicht ein entschlossener Angreifer.

Nein, und ihn für Passwörter oder zur Integritätsprüfung eines Downloads aus einer nicht vertrauenswürdigen Quelle zu verwenden wäre ein schwerer Fehler. Eine CRC ist eine lineare Funktion über dem Körper GF(2), das heißt, dass dieselbe per ODER eingefügte Differenz in zwei Nachrichten dieselbe Differenz in ihren Prüfsummen erzeugt. Wer eine Nachricht und ihre Prüfsumme kennt, kann deshalb eine andere Nachricht konstruieren, die sich in höchstens vier Bytes unterscheidet und jede gewünschte Prüfsumme trägt. Das ist eine Fälschung, die weder Können noch eine Suche erfordert. Da der Wert nur 32 Bit breit ist, kann ein Angreifer zudem in Sekunden auf einer GPU eine Kollision vorberechnen. Es gibt keinen Schlüssel, keine Salze, keinen Kostenfaktor und kein Avalanche-Verhalten, also liefert der CRC keinerlei Einweg-, Unvorhersehbarkeits- oder Brute-Force-Schutzeigenschaften, auf die Passwortspeicherung oder Codesignatur angewiesen sind. Nutzen Sie für Integrität gegenüber einem Angreifer einen kryptografischen Hash wie SHA-256 und für alles, was nach einer Anmeldeinformation aussieht, eine spezielle Funktion wie Argon2id oder bcrypt.

Weil die beiden Namen denselben Algorithmus in leicht unterschiedlichen Rahmungen bezeichnen. Die Zeile CRC-32b in diesem Werkzeug führt exakt dasselbe Verfahren über Ihre Bytes plus ein angehängtes Nullbyte 0x00 aus, und dieses zusätzliche Byte verändert den Registerzustand, sodass sich alle Werte verschieben. Der Zweck einer solchen Variante ist es, die Nutzlast von ihrem eigenen Terminator zu unterscheiden, damit ein Strom, der legitim mit einem Nullbyte endet, nicht mit einem verwechselt wird, der dort zufällig endet. Wichtig zu wissen: Der Begriff wird uneinheitlich verwendet. Die BZIP2-Variante, üblicher als CRC-32/BZIP2 geschrieben und gekennzeichnet durch den Prüfwert 0xCBF43926 für die Zeichenkette 123456789, hängt vier Nullbytes statt eines an und ist eine andere Funktion. Wenn Sie mit einem bestimmten Werkzeug oder Format zusammenarbeiten, prüfen Sie, was diese Implementierung tatsächlich anhängt, statt dem Namen zu vertrauen.

Sie ist die umgekehrte Form des CRC-32-Generatorpolynoms 0x04C11DB7 und taucht in praktisch jeder Softwareimplementierung von CRC-32 auf, der Sie begegnen werden. Das Generatorpolynom legt fest, welche Bitmuster als Fehler gelten. Seine normale Form mit den Bits in Vorwärtsrichtung ist die Darstellung aus Lehrbüchern, aber die umgekehrte Reihenfolge lässt die gesamte Rechnung von rechts nach links durch die Bytes laufen, was eine Tabellenabfrage und eine Verschiebung pro Byte erfordert statt acht bedingter Verschiebungen. In der umgekehrten Implementierung kehrt sich der Wert 0x04C11DB7 zu 0xEDB88320 um, und jeder der 256 Tabelleneinträge entsteht, indem man vom Wert eines Bytes startet und diese Umkehrschleife achtmal anwendet: Ist das niedrigste Bit gesetzt, wird mit 0xEDB88320 ODER-verknüpft und nach rechts verschoben, andernfalls wird nur nach rechts verschoben. Die Tabelle aus dieser Definition zu erzeugen, wie es dieses Werkzeug tut, ist sicherer als ein 256-Einträge-Array einzufügen, weil damit jede Möglichkeit ausgeschlossen ist, dass die ausgelieferte Tabelle von der Definition abweicht, die sie zu implementieren vorgibt.

Weil der Ausgaberaum nur 32 Bit breit ist. Es gibt rund 4,3 Milliarden mögliche Prüfsummen, die sich auf alle erdenklichen Nachrichten verteilen müssen, also ist es unvermeidlich, dass sich einige Nachrichten eine teilen. Nach dem Geburtstagsparadoxon liegt die Zahl der Nachrichten, ab der eine Kollision wahrscheinlich wird, ungefähr bei der Quadratwurzel aus 2^32, also bei etwa 65536; Zufallsdaten treffen in dieser Größenordnung auf eine doppelte Prüfsumme. Echte Dateien sind sogar schlechter als Zufallsdaten, weil strukturierte Dokumente meist nur an wenigen vorhersehbaren Stellen abweichen. Das ist kein Konstruktionsfehler, sondern die Konstruktion, die genau wie vorgesehen funktioniert. Eine CRC-32 erkennt jeden Ein-Bit-Fehler und jeden Burst-Fehler bis 32 Bit mit Sicherheit und deckt damit praktisch alle zufälligen Beschädigungen durch Rauschen, Alterung und Übertragungsfehler ab. Sie kann keine Identität gegenüber einem Angreifer belegen, denn ein Angreifer kann in Sekunden gezielt eine Kollision bauen. Wenn Sie Kollisionsresistenz brauchen, brauchen Sie einen kryptografischen Hash.

Berechnen Sie hier den CRC-32 der Datei und vergleichen Sie ihn mit der Prüfsumme, die der Herausgeber oder das Übertragungssystem hinterlegt hat. Stimmen sie überein, ist die Datei ohne Beschädigung angekommen. Viele Werkzeuge tun das bereits für Sie, denn unzip prüft jeden Eintrag, gzip und zlib prüfen das Stromende und Browser prüfen PNG-Chunks beim Dekodieren. Selbst nachzurechnen bleibt aber der schnellste Weg zu bestätigen, was ein bestimmtes Werkzeug erzeugt hat, und der einzige Weg bei einem ungewöhnlichen Format ohne eingebaute Prüfung. Wählen Sie den Modus File, wählen Sie den Download und lesen Sie die Ausgabe CRC-32 of file. Eine wichtige Einschränkung: Eine übereinstimmende CRC-32 beweist nur dann, dass die Datei die des Herausgebers ist, wenn Sie dem Herausgeber vertrauen. Konnte der Download unterwegs manipuliert werden, kann ein Angreifer mit dieser Fähigkeit eine andere Datei mit gleicher Prüfsumme erzeugen, und genau deshalb gibt es neben Prüfsummen auch GPG- oder Sigstore-signierte Veröffentlichungen.

Nein. Der Rechner ist eine Clientkomponente: Das JavaScript in Ihrem Browser liest Ihren Text, Ihre Hex-Bytes oder die von Ihnen gewählte Datei, baut die CRC-32-Tabelle im Speicher auf und führt die Schleife lokal aus. Nichts wird über das Netzwerk gesendet, nichts in Serverprotokolle geschrieben, und nichts bleibt nach dem Schließen des Tabs bestehen. Für den Dateimodus wird dies über die File-API des Browsers umgesetzt, die die Datei bei Bedarf von der lokalen Platte in den Speicher liest. Das ist praktisch wertvoll, nicht nur datenschutztechnisch: Sie können ein Disk-Image von mehreren Gigabyte oder ein vertrauliches, reguliertes Archiv prüfen, ohne auf einen Upload zu warten und ohne eine Kopie Ihrer Daten an einen Drittanbieter zu übergeben.