Zeilen haben die Form „ALGORITHMUS Wert“, gefolgt von einer eingerückten Parameterzeile, damit ein kopiertes Ergebnis immer angibt, welcher Parametersatz es erzeugt hat.
CRC — zyklische Redundanzprüfung, von Grund auf erklärt
In einem Satz: Ein CRC behandelt Ihre Daten als eine riesige Binärzahl, teilt sie durch eine feste „Generator“-Zahl, wobei XOR statt Subtraktion verwendet wird, und gibt den Rest aus — ein kompakter Fingerabdruck, der sich schon bei einem einzigen geflippten Bit der Eingabe stark ändert. Deshalb trägt alles von PNG-Dateien bis zu Modbus-Leitungen eine solche Prüfsumme.
Was ein CRC eigentlich ist
Das Divisionsbild. Reihen Sie Ihre Bytes als eine lange Binärzahl auf. Wählen Sie einen Divisor — das Polynom, z. B. 0x04C11DB7 für CRC-32. Führen Sie binäre schriftliche Division aus, bei der „Subtraktion“ die XOR-Operation ist: Immer wenn das führende Bit des laufenden Restes 1 ist, XOR mit dem Divisor, nach links schieben, wiederholen. Nachdem die gesamte Nachricht durchlaufen ist, ist das, was im Register übrig bleibt, der CRC. Keine Schlüssel, keine Tabellen in der Definition — nur Division mit Rest.
Die fünf Parameter. Zwei Systeme können beide „CRC-32“ sagen und dennoch unterschiedliche Ergebnisse liefern, weil der Name allein nichts festlegt. Das vollständige Rezept braucht fünf Werte: poly (der Divisor), init (womit das Register startet — Nullen lassen führende Null-Bytes verschwinden, Einsen nicht), refin/refout (ob jedes Eingabebyte — und das Endregister — bitgespiegelt wird, ein Erbe serieller Hardware, die Bits niederwertigstes zuerst sendete) und xorout (eine abschließende XOR-Maske, damit eine Folge nachgestellter Nullen das Ergebnis trotzdem ändert). Diese Seite gibt alle fünf neben jedem Ergebnis aus, genau aus diesem Grund.
Warum er Fehler erkennt. Ein gut gewählter Divisor sorgt dafür, dass sich der Rest einer Nachricht und der Rest derselben Nachricht mit ein paar geflippten Bits mit überwältigender Wahrscheinlichkeit unterscheiden: Ein guter CRC-32 erkennt alle 1-Bit- und 2-Bit-Fehler, alle ungeraden Anzahlen von Bitfehlern und jeden Burst von bis zu 32 aufeinanderfolgenden verfälschten Bits — garantiert, nicht probabilistisch. Diese Garantie betrifft zufällige Verfälschung, und genau das macht CRCs zum richtigen Werkzeug für verrauschte Leitungen und fehleranfällige Festplatten.
Was ein CRC nicht ist
Kein kryptografischer Hash. Es gibt kein Geheimnis und keine Einweg-Eigenschaft: Wer die Parameter kennt, kann eine Nachricht mit jedem beliebigen CRC fälschen, in Millisekunden, indem er vier Korrekturbytes anhängt. Ein CRC erkennt Zufälle, nie Gegner. Für Downloads, die Sie gegenüber Fremden prüfen, zählen Signaturen — siehe stattdessen den Hash-Generator (MD5/SHA/BLAKE2). Dort wird auch erklärt, warum MD5 und SHA-1 für feindliche Einsatzzwecke ausgemustert sind, SHA-256 dagegen Bestand hat.
Kein fehlerkorrigierender Code. Ein CRC sagt Ihnen, dass sich etwas geändert hat, nicht was sich geändert hat. Fehler im Betrieb zu reparieren ist die Aufgabe von Codes wie Reed–Solomon oder Hamming, die bewusst redundante Struktur speichern, die ein Decoder umkehren kann.
Keine Kompression und keine Verschlüsselung. Der Rest sind unabhängig von der Eingabegröße einige Bytes, und daraus lässt sich die Eingabe nicht wiederherstellen — anders als bei einem kryptografischen Hash liegt das aber nur daran, dass Information verworfen wurde, nicht daran, dass die Umkehrung schwer wäre.
Die Familien auf dieser Seite
Das CRC-32-Quartett. Vier Einträge dieser Seite teilen das Polynom 0x04C11DB7 und erzeugen dennoch unterschiedliche Werte: ISO-HDLC (gespiegelt, init/xorout aus Einsen) ist „der“ CRC-32 von zlib, gzip, PNG und ZIP; BZIP2 ist dieselbe Rechnung ungespiegelt; MPEG-2 ist BZIP2 ohne abschließendes XOR; POSIX startet bei null und ist die Grundlage des Befehls cksum (der zusätzlich die Dateilänge an die Division anhängt, weshalb cksum einer Datei und CRC-32/POSIX derselben Bytes verschieden sind). CRC-32C (Castagnoli, Polynom 0x1EDC6F41) ist der fünfte Geschwisterwert: ein anderes Polynom, gewählt für bessere Fehlererkennung, und dasjenige, das moderne x86- und ARM-CPUs mit einem Befehl mit Speichergeschwindigkeit berechnen können.
Das CRC-64-Quartett. XZ verwendet das Polynom aus ECMA-182 in gespiegelter Form mit init und xorout aus Einsen; ECMA-182 selbst ist das ungespiegelte Original mit init Null aus dem DLT-1-Bandstandard; GO-ISO ist crc64.ISO aus Go, ein winziges Polynom 0x1B, weiterhin gespiegelt; REDIS verwendet ein Polynom, das für gute Lawineneigenschaften bei der Zuordnung von Hash-Slots gewählt wurde. Vierundsechzig Bit ist die Größe, bei der CRCs als Hashfunktionen (Bucketing) statt als reine Prüfsummen eingesetzt werden.
Adler-32 ist der Außenseiter: Er ist überhaupt keine Division. Er summiert die Bytes (A, beginnend bei 1) und summiert diese Summen (B), beides modulo 65521, und verkettet die beiden 16-Bit-Summen. In Software ist er schneller als CRC-32, und zlib verwendet ihn für Deflate-Streams — bei kurzen Eingaben (unter einigen hundert Bytes) trägt die Summe aber zu wenig Information, weshalb zlib für kleine Blöcke wieder auf CRC-32 umschaltet.
CRC-8 und CRC-16 überleben dort, wo Bytes teuer sind: CRC-8/CCITT (Polynom 0x07) schützt einzelne Header-Bytes in SMBus- und Mobilfunkprotokollen; CRC-16/CCITT-FALSE sichert Smartcard-Blöcke; CRC-16/MODBUS ist die Prüfsumme jedes Modbus-RTU-Rahmens in Fabriken weltweit.
Wo die einzelnen Varianten vorkommen
| Parametersatz | Gefunden in |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), viele Archivformate |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, SSE4.2/ARMv8-Hardwarebefehl CRC32C |
| CRC-32/BZIP2 | .bz2-Archivstream |
| CRC-32/MPEG-2 | MPEG-2-Transportströme |
| CRC-32/POSIX & cksum | Ausgabe des POSIX-Befehls cksum (cksum file.txt) |
| CRC-16/MODBUS | Modbus-RTU-Rahmen (Industrie-SPS, Zähler, Wechselrichter) |
| CRC-16/CCITT-FALSE | Smartcards, X.25-nahe Verbindungen, einige GPS-Protokolle |
| CRC-8/CCITT | SMBus (PEC-Byte), Mobilfunk-Header |
| CRC-64/XZ | .xz-Container-Integritätsprüfungen |
| CRC-64/ECMA-182 | ECMA-182 / DLT-1-Bandstandard |
| CRC-64/GO-ISO | Go-Standardbibliothek crc64.ISO |
| CRC-64/REDIS | Zuordnung der Hash-Slots im Redis-Cluster |
| Adler-32 | zlib-Streams (Deflate), andere Kontexte mit schnellen Prüfsummen |
Die Ankertabelle — check(„123456789“)
Die Konvention des CRC-Katalogs ist, das Ergebnis für die ASCII-Zeichenkette 123456789 (9 Bytes) zu veröffentlichen. Jeder Wert unten lässt sich auf dieser Seite nachvollziehen: Geben Sie 123456789 in das Textfeld ein, aktivieren Sie den Algorithmus und klicken Sie auf Berechnen.
| Parametersatz | Breite | Prüfwert (hex) |
|---|
| CRC-8/CCITT | 8 | 0xf4 |
| CRC-16/CCITT-FALSE | 16 | 0x29b1 |
| CRC-16/MODBUS | 16 | 0x4b37 |
| CRC-32/ISO-HDLC | 32 | 0xcbf43926 |
| CRC-32C | 32 | 0xe3069283 |
| CRC-32/BZIP2 | 32 | 0xfc891918 |
| CRC-32/MPEG-2 | 32 | 0x0376e6e7 |
| CRC-32/POSIX | 32 | 0x765e7680 |
| cksum (POSIX command) | 32 | 0x377a6011 |
| CRC-64/XZ | 64 | 0x995dc9bbdf1939fa |
| CRC-64/ECMA-182 | 64 | 0x6c40df5f0b497347 |
| CRC-64/GO-ISO | 64 | 0xb90956c775a41001 |
| CRC-64/REDIS | 64 | 0xe9c6d914c4b8d9ca |
| Adler-32 | 32 | 0x091e01de |
Quellen: Jeder Wert wurde mit einer unabhängigen bitweisen Referenzimplementierung gegengeprüft und, wo vorhanden, mit der Systembibliothek abgeglichen, die den Algorithmus ausliefert (zlib für CRC-32 und Adler-32; der CRC-Katalog von Greg Cook für die übrigen).
Häufige Fehler
- „CRC-32“ ohne Parameter. Zwischen ISO-HDLC, BZIP2, MPEG-2, POSIX und CRC-32C kursieren fünf verschiedene Werte unter demselben Namen. Notieren Sie immer poly/init/refin/refout/xorout zusammen mit dem Ergebnis — diese Seite gibt sie für Sie aus.
- Den CRC-32 einer Datei mit ihrer
cksum-Ausgabe vergleichen. Verschiedene Algorithmen: cksum hängt die Länge an und verwendet einen anderen init-Wert. Die Zahlen stimmen nicht überein, und beide sind „richtig“.
- Einem CRC gegen Manipulation vertrauen. Einen passenden CRC zu fälschen ist eine Standardübung (die letzten 4 Bytes anpassen). Verwenden Sie eine MAC mit Schlüssel (HMAC) oder eine Signatur, wenn die Gegenseite feindlich gesinnt sein könnte.
- Lawineneffekt erwarten. Ein CRC ist linear: verwandte Nachrichten ergeben verwandte CRCs. Für Rauschen geeignet, für Hashing falsch — wenn Sie Bucketing brauchen, sind CRC-64 oder ein echter Hash sicherer als CRC-32.
- Hex-Text gegen Bytes. Die Zeichenkette
"123456789" (9 ASCII-Bytes, 31 32 33 34 35 36 37 38 39) und die Zahl 0x123456789 sind verschiedene Eingaben mit unterschiedlichen CRCs. Verwenden Sie den Reiter Hex-Bytes, wenn Ihre Quelldaten wirklich binär sind.
FAQ
Warum stimmt mein CRC-32 nicht mit dem in der ZIP-Datei überein? Der CRC-32 von ZIP ist ISO-HDLC über die unkomprimierten Daten. Achten Sie darauf, dieselben Bytes (nicht den komprimierten Stream), denselben Modus (Text oder Hex) und denselben Parametersatz zu verwenden — die Parameterzeile unter jedem Ergebnis macht diese Prüfung sofort möglich.
Was ist besser, CRC-32C oder CRC-32? Zur Erkennung zufälliger Fehler erkennen beide alle Bursts bis 32 Bit; CRC-32C arbeitet bei manchen Fehlermustern besser und ist die Variante mit CPU-Befehlen — bei Gigabit-Geschwindigkeiten praktisch kostenlos. Dass CRC-32/ISO-HDLC weiterlebt, liegt an der Kompatibilität: Dreißig Jahre Archive sprechen diesen Standard.
Ist CRC-64 stärker als CRC-32? Er erkennt längere Bursts (bis 64 Bit) und kollidiert beim Bucketing viel seltener, ist aber genauso fälschbar — die Breite bringt Erkennungsgarantien, keine Sicherheit.
Lässt sich ein CRC rückwärts auflösen, um die Eingabe zu ermitteln? Nein — unendlich viele Eingaben teilen sich einen CRC. Anders als bei einem kryptografischen Hash kann ein Angreifer aber eine Eingabe mit jedem gewünschten CRC konstruieren — in diesem Sinne ist er gar nicht einweg.
