CRC-Prüfsummenrechner (CRC-8/16/32/64)

Ein Cyclic Redundancy Check behandelt die Eingabemeldung als großes binäres Polynom und teilt es durch ein festes Generator-Polynom; der Rest ist die Prüfsumme. CRCs sollen versehentliche Fehler bei Übertragung oder Speicherung erkennen – Bitumkehrungen, verloren gegangene Bytes oder vertauschte Laufzeiten – und tun dies sehr effizient. Kryptographische Hashes wie SHA-256 lösen ein anderes Problem: Sie sind kollisionsresistent und sollen gegen fremde Manipulationen bestehen. CRCs sind schnell und mathematisch vorhersagbar, aber leicht zu fälschen, daher sollten sie niemals für Sicherheitszwecke verwendet werden.

Verschiedene Standardsorganisationen und Hersteller wählen unterschiedliche Generator-Polynome, Anfangswerte für den Register, Bitspiegelungseinstellungen und End-XOR-Werte, um ihre Fehlererkennung zu optimieren. Ethernet, ZIP und PNG haben sich auf CRC-32 (IEEE 802.3) geeinigt, während industrielle Protokolle wie MODBUS, USB und XMODEM ihre eigenen CRC-16-Varianten standardisiert haben. Zwei Varianten mit derselben Bitbreite erzeugen für die gleiche Eingabe völlig unterschiedliche Prüfsummen, wenn sich irgendein Parameter unterscheidet – daher ist es entscheidend, die exakte Variante auszuwählen, die mit Ihrem Ziel-System übereinstimmt.

Reflektierte (manchmal auch umgekehrte) Varianten verarbeiten jeden Byte von der kleinsten bis zur größten Bitstelle und spiegeln das Endregister bit für bit vor der Ausgabe XOR. Nicht-reflektierte Varianten verarbeiten die Bits in der größten Bitreihenfolge. Diese Wahl entstand in Hardware-Designs, bei denen eine Registerverschiebung in einer Richtung günstiger war als in der anderen. Zwei CRCs mit demselben Polynom, aber unterschiedlichen Spiegelungseinstellungen, sind nicht kompatibel – CRC-32 und CRC-32/BZIP2 teilen das gleiche Polynom 0x04C11DB7, erzeugen jedoch völlig unterschiedliche Werte.

CRC-32C, veröffentlicht von Guy Castagnoli im Jahr 1993, verwendet das Polynom 0x1EDC6F41 anstatt 0x04C11DB7. Seine Fehlererkennungseigenschaften sind mathematisch für kurze Datenpakete überlegen, und moderne x86-Prozessoren implementieren es direkt in einer einzigen CRC32-Befehl. Es wird als Prüfsumme bei iSCSI, SCTP, ext4-Metadaten, Btrfs und Google’s gRPC-Framing-Schicht verwendet. Wenn hohe Durchsatzgeschwindigkeit und starke Fehlererkennung beide wichtig sind, bevorzugen Systeme zunehmend CRC-32C gegenüber dem klassischen Ethernet-CRC.

Kein Fehlererkennungssystem erkennt alles. Ein n-Bit-CRC garantiert die Erkennung aller Burst-Fehler bis zu n Bit und aller einzelnen Bitfehler, aber etwa 1 von 2^n zufällige Störungen werden unerkannt bleiben. Bei CRC-32 beträgt das etwa 1 von 4,3 Milliarden – hervorragend für gewöhnliche Datei- und Rahmenintegrität. Bei sehr großen Dateien oder langfristiger Speicherung erweitert CRC-64 diese Grenze auf etwa 1 von 1,8 × 10^19. Bei gezielten Manipulationen ist die Situation anders: Angreifer können immer eine Nachricht so anpassen, dass ihre CRC einem gewünschten Wert entspricht – deshalb müssen Prüfsummen niemals anstelle von digitalen Signaturen für Authentifizierung verwendet werden.