Zusammenfassung

  • RFC 3385 zeigte, dass „32-Bit-Prüfsumme“ keine vollständige Schutzbeschreibung war: Generatorpolynom, Blocklänge, Fehlerverteilung und Datendichte veränderten die Nichterkennung.
  • CRC32C galt unter benannten Annahmen über zufällige Beschädigung als gute iSCSI-Grundlage, nie als kryptografische oder universelle Garantie.

Ein gebündelter Bitfehler passiert eine additive Summe und bleibt in einem CRC-Gitter hängen. Beide Ergebnisse brauchen vier Byte. Die Breite beschreibt Redundanzmenge, nicht die Fehlermuster, die ein Code unterscheidet. RFC 3385 machte diese verborgene Differenz zur überprüfbaren Entscheidung.

Das Informational RFC erschien im September 2002. Es schätzte unerkannte Fehler, um die iSCSI-Auswahl zu unterstützen. Es war weder das vollständige Protokoll noch Produktzertifikat oder Feldbericht. Seine Zahlen galten innerhalb erklärter Modelle.

iSCSI transportierte SCSI-Befehle und Speicherdaten über IP. Unbemerkte Beschädigung konnte als scheinbar gültiger Inhalt auf einem Datenträger landen. Bei Petabyte-Mengen wurde selbst kleine Exposition relevant; der Text verlangte gutes Verhalten mindestens bis 8-KiB-Blöcken.

RFC 3347 hatte erklärt, warum der TCP-Checksum nicht genügte. Manche Fehler konnten passieren. Proxy oder Gateway konnten TCP terminieren, iSCSI-Header neu bauen und den Checksum neu berechnen. Daten, Befehle und Status brauchten daher eine eigene Digest-Grenze.

RFC 3385 trennte Burstfehler von unabhängigen Bitfehlern. Auch Speicher, interne Verbindungen oder Software konnten gebündelte Schäden erzeugen. Nicht nur Anzahl, sondern Verteilung, Dauer und Blocklänge bestimmten das Risiko.

Ein CRC berechnet Redundanz mit einem Generatorpolynom. Ein fehlerhaftes Wort bleibt nur dann unentdeckt, wenn das Fehlermuster selbst Codewortstruktur hat. Mindestabstand und Gewichtsverteilung formen die Blindfläche. 32 Bit beschreiben Menge, nicht Geometrie.

Bei verkürzten Codes konnten Polynome gleichen Grades bei praktischen Längen stark differieren. Zitierte Forschung fand für bestimmte Bursts Größenordnungen Abstand zwischen 32-Bit-Polynomen. Eine Breitenklasse hätte den entscheidenden Unterschied gelöscht.

IEEE-802-CRC und CRC32C waren beide 32 Bit, doch CRC32C nutzte 0x11EDC6F41. Das Polynom änderte Teilbarkeit, Abstand und Nichterkennungsfläche. Es war kein austauschbares Implementierungsdetail.

Die Rechnungen setzten Burstrate, unabhängige Fehlerrate, Dauerverteilung und 8-KiB-Block voraus. Ein zeitlich gleich langer Burst umfasst bei höherer Geschwindigkeit mehr Bits. Wer Kanal, Last, Länge oder Verteilung ändert, ändert die Aussage. Extrem kleine Zahlen sind keine Garantien ohne Annahmen.

Unter den analysierten Bedingungen wurde CRC etwa 12.000-mal besser als Fletcher und 22.000-mal besser als Adler geschätzt. Kurze Muster konnten sich in additiven Summen aufheben. Reale, verzerrte Daten verschärften solche Hotspots.

Die Abschlusstabelle stellte Fletcher32, Adler32, IEEE-802 und CRC32C nebeneinander: gleiche Breite, andere Abstände und modellierte Wahrscheinlichkeiten. Schutz, geringere Empfindlichkeit gegen Datenbias und lange Blöcke begründeten die CRC32C-Wahl.

Auch Kosten wurden gemessen. CRC32C benötigte in der zitierten Synthese mehr Zellen als CCITT-CRC32, blieb aber unter einem Prozent eines repräsentativen Millionen-Zellen-Chips. Die Abwägung verschwieg Kosten nicht, sondern skalierte sie.

Interoperabilität verlangte Bitreihenfolge, Initialisierung, Komplement, Padding und Restabbildung. Serien- und Parallelhardware sowie Softwaretabellen konnten dasselbe Polynom verschieden darstellen. Der Name allein reichte nicht.

Linearität erlaubte inkrementelle CRC-Anpassung, wenn ein Zwischenknoten Header änderte. Das Endziel konnte weiter den Gesamtpfad prüfen. Diese Eigenschaft sparte Arbeit und deckte zufällige Zwischenänderungen ab; sie authentisierte den Knoten nicht.

RFC 7143 konsolidierte später iSCSI. HeaderDigest und DataDigest haben None als Standard; Initiator und Target müssen CRC32C und None implementieren. Nach Aushandlung gilt der Digest in der Full Feature Phase. Er wird ausdrücklich nicht kryptografisch genannt.

Implementiert, angeboten, gewählt, abgedeckt, erfolgreich geprüft und nach iSCSI weiter geschützt sind verschiedene Tatsachen. Kompatibilität beweist keine Aktivierung in jeder Sitzung.

Die Sicherheitsgrenze war klar: Ein Angreifer, der Daten ändert, kann den Code passend ändern. CRC erkennt Zufallsschäden, authentisiert aber weder Ursprung noch Berechtigung. Bestehen ist kein Beleg gegen aktive Angriffe.

RFC 3309, RFC 4960 und RFC 9260 verwendeten CRC32C auch für SCTP. Das zeigt Wiederverwendung, nicht identische Modelle. Länge, Felder, Unterbau und Wiederherstellung verändern den Evidenzwert.

RFC 1071 beschrieb den Internet-Checksum; RFC 1141 und RFC 1624 inkrementelle Aktualisierung, wobei das spätere Dokument ein Problem korrigierte. RFC 2151 behandelte Fletcher für UDP, RFC 1950 Adler-32 für zlib. „Checksum“ ist eine Familie, kein einheitliches Schutzniveau.

Der Text warnte außerdem: Schnellere Kanäle machen zeitlich feste Bursts in Bits länger. Ein besserer CRC stabilisiert das Risiko nicht allein. Untere Codierung und Fehlerrate bleiben Teil der Kontrolle.

Lu Hengs minimale Anfangsspezifikation lokalisiert die gemeinsame Entscheidung in Polynom, Darstellung und Abdeckung. Hardware und Software dürfen danach optimieren. Freiheit beginnt erst, wenn „bestanden“ überall dasselbe bedeutet.

Die Realitätsebenen trennen Feld vorhanden, Algorithmus implementiert, Digest ausgehandelt, PDU umfasst, Wert bestanden, Zufallsschaden im Modell ausgeschlossen und adversarische Integrität. „32-Bit-Prüfsumme“ verdichtet sieben Fakten und beweist fast keinen.

RFC 3385 empfahl somit nicht nur CRC32C. Es verwandelte ein Integritätslabel in eine begrenzte Evidenzaussage. Die Bits waren Hülle; Polynom, Block, Last, Pfad und Bedrohung gaben ihr Bedeutung.

Quellen