Wie wird eine CRC32-Prüfsumme berechnet?

Vielleicht sehe ich es einfach nicht, aber CRC32 scheint entweder unnötig kompliziert oder unzureichend erklärt zu sein, wo immer ich es im Web finden kann.

Ich verstehe, dass es der Rest einer nicht Carry-basierten arithmetischen Division des Nachrichtenwerts ist, geteilt durch das (Generator-) Polynom, aber die tatsächliche Implementierung davon entgeht mir.

Ich habe einen schmerzlosen Leitfaden zu CRC-Fehlererkennungsalgorithmen gelesen , und ich muss sagen, dass er nicht schmerzlos war. Es geht ziemlich gut über die Theorie, aber der Autor kommt nie zu einem einfachen "das ist es". Er sagt zwar, welche Parameter für den Standard-CRC32-Algorithmus gelten, vernachlässigt jedoch, klar darzulegen, wie Sie dazu gelangen.

Der Teil, der mich erwischt, ist, wenn er sagt "das ist es" und dann hinzufügt: "Oh, übrigens, es kann umgekehrt oder mit unterschiedlichen Anfangsbedingungen begonnen werden" und keine klare Antwort auf den endgültigen Weg gibt der Berechnung einer CRC32-Prüfsumme unter Berücksichtigung aller Änderungen, die er gerade hinzugefügt hat.

• Gibt es eine einfachere Erklärung für die Berechnung von CRC32?

Ich habe versucht, in C zu codieren, wie die Tabelle gebildet wird:

for (i = 0; i < 256; i++)
{
    temp = i;

    for (j = 0; j < 8; j++)
    {
        if (temp & 1)
        {
            temp >>= 1;
            temp ^= 0xEDB88320;
        }
        else {temp >>= 1;}
    }
    testcrc[i] = temp;
}

Dies scheint jedoch Werte zu erzeugen, die nicht mit den Werten übereinstimmen, die ich an anderer Stelle im Internet gefunden habe. Ich könnte die online gefundenen Werte verwenden, möchte aber verstehen, wie sie erstellt wurden.

Jede Hilfe bei der Aufklärung dieser unglaublich verwirrenden Zahlen wäre sehr dankbar.

Das Polynom für CRC32 lautet:

x ³² + x ²⁶ + x ²³ + x ²² + x ¹⁶ + x ¹² + x ¹¹ + x ¹⁰ + x ⁸ + x ⁷ + x ⁵ + x ⁴ + x ² + x + 1

• Wikipedia
• CRC-Berechnung

Oder in hex und binär:

0x 01 04 C1 1D B7
1 0000 0100 1100 0001 0001 1101 1011 0111

Der höchste Term (x ³² ) wird normalerweise nicht explizit geschrieben, daher kann er genauso wie in hexadezimaler Darstellung dargestellt werden

0x 04 C1 1D B7

Fühlen Sie sich frei, die Einsen und Nullen zu zählen, aber Sie werden feststellen, dass sie mit dem Polynom übereinstimmen, wobei 1Bit 0 (oder das erste Bit) und xBit 1 (oder das zweite Bit) ist.

Warum dieses Polynom? Weil es einen Standard für ein Polynom geben muss und der Standard von IEEE 802.3 festgelegt wurde. Es ist auch äußerst schwierig, ein Polynom zu finden, das verschiedene Bitfehler effektiv erkennt.

Sie können sich den CRC-32 als eine Reihe von "Binärarithmetik ohne Träger" oder im Grunde als "XOR- und Schichtoperationen" vorstellen. Dies wird technisch als Polynomarithmetik bezeichnet.

• CRC-Primer, Kapitel 5

Um es besser zu verstehen, denken Sie an diese Multiplikation:

(x^3 + x^2 + x^0)(x^3 + x^1 + x^0)
= (x^6 + x^4 + x^3
 + x^5 + x^3 + x^2
 + x^3 + x^1 + x^0)
= x^6 + x^5 + x^4 + 3*x^3 + x^2 + x^1 + x^0

Wenn wir annehmen, dass x Basis 2 ist, erhalten wir:

x^7 + x^3 + x^2 + x^1 + x^0

• CRC-Primer Chp.5

Warum? Da 3x ^ 3 11x ^ 11 ist (aber wir brauchen nur 1 oder 0 Vorziffer), übertragen wir:

=1x^110 + 1x^101 + 1x^100          + 11x^11 + 1x^10 + 1x^1 + x^0
=1x^110 + 1x^101 + 1x^100 + 1x^100 + 1x^11 + 1x^10 + 1x^1 + x^0
=1x^110 + 1x^101 + 1x^101          + 1x^11 + 1x^10 + 1x^1 + x^0
=1x^110 + 1x^110                   + 1x^11 + 1x^10 + 1x^1 + x^0
=1x^111                            + 1x^11 + 1x^10 + 1x^1 + x^0

Aber Mathematiker haben die Regeln so geändert, dass es Mod 2 ist. Im Grunde genommen ist jedes binäre Polynom Mod 2 nur eine Addition ohne Carry oder XORs. Unsere ursprüngliche Gleichung sieht also so aus:

=( 1x^110 + 1x^101 + 1x^100 + 11x^11 + 1x^10 + 1x^1 + x^0 ) MOD 2
=( 1x^110 + 1x^101 + 1x^100 +  1x^11 + 1x^10 + 1x^1 + x^0 )
= x^6 + x^5 + x^4 + 3*x^3 + x^2 + x^1 + x^0 (or that original number we had)

Ich weiß, dass dies ein Glaubenssprung ist, aber dies übersteigt meine Fähigkeiten als Linienprogrammierer. Wenn Sie ein Hardcore-CS-Student oder Ingenieur sind, fordere ich Sie auf, dies aufzuschlüsseln. Jeder wird von dieser Analyse profitieren.

Um ein vollständiges Beispiel zu erarbeiten:

   Original message                : 1101011011
   Polynomial of (W)idth 4         :      10011
   Message after appending W zeros : 11010110110000

Jetzt teilen wir die erweiterte Nachricht durch die Poly mithilfe der CRC-Arithmetik. Dies ist die gleiche Unterteilung wie zuvor:

            1100001010 = Quotient (nobody cares about the quotient)
       _______________
10011 ) 11010110110000 = Augmented message (1101011011 + 0000)
=Poly   10011,,.,,....
        -----,,.,,....
         10011,.,,....
         10011,.,,....
         -----,.,,....
          00001.,,....
          00000.,,....
          -----.,,....
           00010,,....
           00000,,....
           -----,,....
            00101,....
            00000,....
            -----,....
             01011....
             00000....
             -----....
              10110...
              10011...
              -----...
               01010..
               00000..
               -----..
                10100.
                10011.
                -----.
                 01110
                 00000
                 -----
                  1110 = Remainder = THE CHECKSUM!!!!

Die Division ergibt einen Quotienten, den wir wegwerfen, und einen Rest, der die berechnete Prüfsumme ist. Damit ist die Berechnung beendet. Normalerweise wird die Prüfsumme dann an die Nachricht angehängt und das Ergebnis übertragen. In diesem Fall wäre die Übertragung: 11010110111110.

• CRC-Primer, Kapitel 7

Verwenden Sie nur eine 32-Bit-Zahl als Divisor und Ihren gesamten Stream als Dividende. Wirf den Quotienten raus und behalte den Rest. Heften Sie den Rest am Ende Ihrer Nachricht an und Sie haben einen CRC32.

Durchschnittliche Bewertung:

         QUOTIENT
        ----------
DIVISOR ) DIVIDEND
                 = REMAINDER

1. Nimm die ersten 32 Bits.
2. Bits verschieben
3. Wenn 32 Bit kleiner als DIVISOR sind, fahren Sie mit Schritt 2 fort.
4. XOR 32 Bit von DIVISOR. Weiter zu Schritt 2.

(Beachten Sie, dass der Stream durch 32 Bit teilbar sein muss oder aufgefüllt werden muss. Beispielsweise müsste ein 8-Bit-ANSI-Stream aufgefüllt werden. Auch am Ende des Streams wird die Teilung angehalten.)

Für IEEE802.3 CRC-32. Stellen Sie sich die gesamte Nachricht als seriellen Bitstrom vor und hängen Sie 32 Nullen an das Ende der Nachricht an. Als nächstes MÜSSEN Sie die Bits JEDES Bytes der Nachricht umkehren und die ersten 32 Bits durch eine 1 ergänzen. Teilen Sie nun durch das CRC-32-Polynom 0x104C11DB7. Schließlich müssen Sie den 32-Bit-Rest dieser Division durch 1 ergänzen und jedes der 4 Bytes des Restes bitumkehren. Dies wird die 32-Bit-CRC, die an das Ende der Nachricht angehängt wird.

Der Grund für diese seltsame Prozedur ist, dass die ersten Ethernet-Implementierungen die Nachricht byteweise serialisieren und das niedrigstwertige Bit jedes Bytes zuerst übertragen. Der serielle Bitstrom durchlief dann eine serielle CRC-32-Schieberegisterberechnung, die einfach ergänzt und nach Abschluss der Nachricht auf der Leitung gesendet wurde. Der Grund für das Ergänzen der ersten 32 Bits der Nachricht ist, dass Sie keine CRC mit allen Nullen erhalten, selbst wenn die Nachricht nur Nullen war.

Ein CRC ist ziemlich einfach; Sie nehmen ein Polynom, das als Bits und Daten dargestellt wird, und teilen das Polynom in die Daten (oder Sie stellen die Daten als Polynom dar und tun dasselbe). Der Rest, der zwischen 0 und dem Polynom liegt, ist der CRC. Ihr Code ist etwas schwer zu verstehen, auch weil er unvollständig ist: temp und testcrc werden nicht deklariert, daher ist unklar, was indiziert wird und wie viele Daten durch den Algorithmus laufen.

Der Weg, CRCs zu verstehen, besteht darin, zu versuchen, einige mit einem kurzen Datenelement (ca. 16 Bit) mit einem kurzen Polynom zu berechnen - vielleicht 4 Bit. Wenn Sie auf diese Weise üben, werden Sie wirklich verstehen, wie Sie es codieren können.

Wenn Sie dies häufig tun, ist die Berechnung eines CRC in Software recht langsam. Hardware-Berechnungen sind viel effizienter und erfordern nur wenige Gates.

Zusätzlich zur zyklischen Redundanzprüfung und Berechnung von CRC- Artikeln in Wikipedia fand ich ein Papier mit dem Titel Reversing CRC - Theory and Practice ^* als gute Referenz.

Es gibt im Wesentlichen drei Ansätze zur Berechnung eines CRC: einen algebraischen Ansatz, einen bitorientierten Ansatz und einen tabellengesteuerten Ansatz. In Umkehrung von CRC - Theorie und Praxis ^* wird jeder dieser drei Algorithmen / Ansätze theoretisch im ANHANG mit einer Implementierung für CRC32 in der Programmiersprache C erläutert.

^{* PDF Link
Umkehrung von CRC - Theorie und Praxis.
HU Berlin Öffentlicher Bericht
SAR-PR-2006-05
Mai 2006
Autoren:
Martin Stigge, Henryk Plötz, Wolf Müller, Jens-Peter Redlich}

Ich habe eine Weile versucht, die Antwort auf diese Frage zu finden, und heute endlich ein Tutorial zu CRC-32 veröffentlicht: CRC-32-Hash-Tutorial - AutoHotkey Community

In diesem Beispiel zeige ich, wie der CRC-32-Hash für die ASCII-Zeichenfolge 'abc' berechnet wird:

calculate the CRC-32 hash for the ASCII string 'abc':

inputs:
dividend: binary for 'abc': 0b011000010110001001100011 = 0x616263
polynomial: 0b100000100110000010001110110110111 = 0x104C11DB7

011000010110001001100011
reverse bits in each byte:
100001100100011011000110
append 32 0 bits:
10000110010001101100011000000000000000000000000000000000
XOR the first 4 bytes with 0xFFFFFFFF:
01111001101110010011100111111111000000000000000000000000

'CRC division':
01111001101110010011100111111111000000000000000000000000
 100000100110000010001110110110111
 ---------------------------------
  111000100010010111111010010010110
  100000100110000010001110110110111
  ---------------------------------
   110000001000101011101001001000010
   100000100110000010001110110110111
   ---------------------------------
    100001011101010011001111111101010
    100000100110000010001110110110111
    ---------------------------------
         111101101000100000100101110100000
         100000100110000010001110110110111
         ---------------------------------
          111010011101000101010110000101110
          100000100110000010001110110110111
          ---------------------------------
           110101110110001110110001100110010
           100000100110000010001110110110111
           ---------------------------------
            101010100000011001111110100001010
            100000100110000010001110110110111
            ---------------------------------
              101000011001101111000001011110100
              100000100110000010001110110110111
              ---------------------------------
                100011111110110100111110100001100
                100000100110000010001110110110111
                ---------------------------------
                    110110001101101100000101110110000
                    100000100110000010001110110110111
                    ---------------------------------
                     101101010111011100010110000001110
                     100000100110000010001110110110111
                     ---------------------------------
                       110111000101111001100011011100100
                       100000100110000010001110110110111
                       ---------------------------------
                        10111100011111011101101101010011

remainder: 0b10111100011111011101101101010011 = 0xBC7DDB53
XOR the remainder with 0xFFFFFFFF:
0b01000011100000100010010010101100 = 0x438224AC
reverse bits:
0b00110101001001000100000111000010 = 0x352441C2

thus the CRC-32 hash for the ASCII string 'abc' is 0x352441C2

Dann gibt es immer Rosetta Code, der zeigt, dass crc32 in Dutzenden von Computersprachen implementiert ist. https://rosettacode.org/wiki/CRC-32 und enthält Links zu vielen Erklärungen und Implementierungen.

Um crc32 auf die Erinnerung zu reduzieren, müssen Sie:

1. Bits auf jedem Byte invertieren
2. xoder die ersten vier Bytes mit 0xFF (um Fehler bei den führenden Nullen zu vermeiden)
3. Fügen Sie am Ende eine Auffüllung hinzu (damit die letzten 4 Bytes am Hash teilnehmen)
4. Berechnen Sie die Erinnerung
5. Kehren Sie die Bits erneut um
6. xoder das Ergebnis erneut.

Im Code ist dies:

func CRC32 (file []byte) uint32 {
    for i , v := range(file) {
        file[i] = bits.Reverse8(v)
    }
    for i := 0; i < 4; i++ {
        file[i] ^= 0xFF
    }

    // Add padding
    file = append(file, []byte{0, 0, 0, 0}...)
    newReminder := bits.Reverse32(reminderIEEE(file))

    return newReminder ^ 0xFFFFFFFF
}

wobei memorIEEE die reine Erinnerung an GF (2) ist [x]