Regels hebben de vorm “ALGORITME waarde” gevolgd door een ingesprongen parameterregel, zodat een gekopieerd resultaat altijd zegt welke parameterset het heeft opgeleverd.
CRC — cyclische redundantiecontrole, van nul af uitgelegd
In één zin: een CRC behandelt uw gegevens als één reusachtig binair getal, deelt het door een vast “generator”-getal met XOR in plaats van aftrekken, en rapporteert de rest — een compacte vingerafdruk die sterk verandert wanneer zelfs één bit van de invoer omklapt, daarom draagt alles van PNG-bestanden tot Modbus-kabels er een.
Wat een CRC werkelijk is
Het deelbeeld. Leg uw bytes achter elkaar als één lang binair getal. Kies een deler — de polynoom, bijvoorbeeld 0x04C11DB7 voor CRC-32. Voer binaire staartdeling uit waarbij “aftrekken” de XOR-bewerking is: telkens wanneer het eerste bit van de lopende rest 1 is, XOR de deler erin, schuif naar links, herhaal. Nadat het hele bericht is doorgelopen, is wat in het register overblijft de CRC. Geen sleutels, geen tabellen in de definitie — gewoon deling met een rest.
De vijf parameters. Twee systemen kunnen allebei “CRC-32” zeggen en toch van mening verschillen, omdat de naam alleen niets vastlegt. Het volledige recept heeft vijf waarden nodig: poly (de deler), init (waarmee het register begint — alle nullen laten voorloopnullen verdwijnen, alle enen niet), refin/refout (of elke invoerbyte — en het eindregister — bitsgewijs wordt omgekeerd, een erfenis van seriële hardware die bits van laag naar hoog verstuurde), en xorout (een eindmasker met XOR zodat een reeks nullen aan het einde het antwoord nog steeds verandert). Deze pagina drukt alle vijf naast elk resultaat af om precies die reden.
Waarom het fouten detecteert. Een goed gekozen deler maakt de rest van een bericht en de rest van hetzelfde bericht met enkele omgeklapte bits met overweldigende waarschijnlijkheid verschillend: een goede CRC-32 vangt alle 1-bit- en 2-bit-fouten, alle oneven aantallen bitfouten en elke burst van maximaal 32 opeenvolgende beschadigde bits — gegarandeerd, niet probabilistisch. Die garantie gaat over toevallige beschadiging, en daardoor zijn CRC's het juiste hulpmiddel voor ruisende kabels en wankele schijven.
Wat een CRC niet is
Geen cryptografische hash. Er is geen geheim en geen eenrichtingsfunctie: iedereen die de parameters kent kan in milliseconden een bericht vervalsen met elke gewenste CRC, door vier correctiebytes toe te voegen. Een CRC detecteert ongelukken, nooit tegenstanders. Voor downloads die u verifieert tegen onbekenden zijn handtekeningen belangrijk — zie in plaats daarvan de Hashgenerator (MD5/SHA/BLAKE2). Die pagina legt ook uit waarom MD5 en SHA-1 voor vijandige omstandigheden zijn uitgefaseerd terwijl SHA-256 standhoudt.
Geen foutcorrigerende code. Een CRC vertelt u dat er iets is veranderd, niet wat er is veranderd. Fouten on the fly herstellen is het werk van codes zoals Reed–Solomon of Hamming, die bewust overbodige structuur opslaan die een decoder kan omkeren.
Geen compressie of versleuteling. De rest is een paar bytes ongeacht de invoergrootte, en daaruit kunt u de invoer niet herstellen — maar anders dan bij een cryptografische hash is dat alleen omdat informatie is weggegooid, niet omdat omkering moeilijk is.
De families op deze pagina
Het CRC-32-kwartet. Vier vermeldingen op deze pagina delen de poly 0x04C11DB7 en leveren toch verschillende waarden op: ISO-HDLC (gespiegeld, init/xorout alle enen) is “de” CRC-32 van zlib, gzip, PNG en ZIP; BZIP2 is dezelfde wiskunde ongespiegeld; MPEG-2 is BZIP2 zonder eindige XOR; POSIX begint bij nul en is de basis van het commando cksum (dat bovendien de bestandslengte aan de deling toevoegt, dus cksum van een bestand en CRC-32/POSIX van dezelfde bytes verschillen). CRC-32C (Castagnoli, poly 0x1EDC6F41) is de vijfde zus: een andere poly, gekozen voor betere foutdetectie, en de variant die moderne x86- en ARM-CPU's met één instructie op geheugensnelheid kunnen berekenen.
Het CRC-64-kwartet. XZ gebruikt de ECMA-182-polynoom in gespiegelde vorm met alle-enen-init en xorout; ECMA-182 zelf is het ongespiegelde origineel met nul-init van de DLT-1-bandstandaard; GO-ISO is Go's crc64.ISO, een kleine poly 0x1B, nog steeds gespiegeld; REDIS gebruikt een poly die is gekozen voor goed lawine-effect bij toewijzing van hash-slots. Vierenzestig bits is de grootte waarbij CRC's begin worden gebruikt als hashfuncties (bucketing) in plaats van pure controlesommen.
Adler-32 is de buitenstaander: het is helemaal geen deling. Het telt de bytes op (A, beginnend bij 1) en telt die sommen op (B), beide modulo 65521, en plakt de twee 16-bits sommen aan elkaar. Het is sneller dan CRC-32 in software en zlib gebruikt het voor deflate-streams — maar bij korte invoer (onder enkele honderden bytes) draagt de som te weinig informatie, precies waarom zlib voor kleine blokken terugschakelt naar CRC-32.
CRC-8 en CRC-16 overleven waar bytes duur zijn: CRC-8/CCITT (poly 0x07) beschermt losse headerbytes in SMBus- en mobiele-radioprotocollen; CRC-16/CCITT-FALSE beveiligt chipkaartblokken; CRC-16/MODBUS is de controlesom van elk Modbus RTU-frame op fabrieksvloeren wereldwijd.
Waar elke variant voorkomt
| Parameterset | Gevonden in |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), veel archiefformaten |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, SSE4.2/ARMv8 hardware-CRC32C-instructie |
| CRC-32/BZIP2 | .bz2-archiefstroom |
| CRC-32/MPEG-2 | MPEG-2-transportstromen |
| CRC-32/POSIX & cksum | Uitvoer van het POSIX-commando cksum (cksum file.txt) |
| CRC-16/MODBUS | Modbus RTU-frames (industriële PLC's, meters, omvormers) |
| CRC-16/CCITT-FALSE | chipkaarten, X.25-verwante verbindingen, sommige GPS-protocollen |
| CRC-8/CCITT | SMBus (PEC-byte), mobiele-radioheaders |
| CRC-64/XZ | .xz-containerintegriteitscontroles |
| CRC-64/ECMA-182 | ECMA-182 / DLT-1-bandstandaard |
| CRC-64/GO-ISO | Go-standaardbibliotheek crc64.ISO |
| CRC-64/REDIS | Redis-cluster hash-slottoewijzing |
| Adler-32 | zlib-streams (deflate), andere contexten met snelle controlesommen |
De ankertabel — check(“123456789”)
De conventie van de CRC-catalogus is het resultaat voor de ASCII-string 123456789 (9 bytes) te publiceren. Elke waarde hieronder is op deze pagina reproduceerbaar: typ 123456789 in het tekstvak, vink het algoritme aan en klik op Berekenen.
| Parameterset | Breedte | Controlewaarde (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 |
Bronnen: elke waarde is gekruiscontroleerd met een onafhankelijke bitsgewijze referentie-implementatie en, waar die bestaat, met de systeembibliotheek die het algoritme levert (zlib voor CRC-32 en Adler-32; de CRC-catalogus van Greg Cook voor de rest).
Veelgemaakte fouten
- “CRC-32” zonder parameters. Tussen ISO-HDLC, BZIP2, MPEG-2, POSIX en CRC-32C circuleren vijf verschillende waarden onder dezelfde naam. Noteer altijd poly/init/refin/refout/xorout bij het resultaat — deze pagina drukt ze voor u af.
- Het CRC-32 van een bestand vergelijken met de
cksum-uitvoer. Verschillende algoritmen: cksum voegt de lengte toe en gebruikt een andere init. De getallen komen niet overeen, en beide zijn “correct”.
- CRC vertrouwen tegen manipulatie. Een passende CRC vervalsen is een klassieke oefening (de laatste 4 bytes aanpassen). Gebruik een gesleuteld MAC (HMAC) of een handtekening wanneer de andere partij vijandig kan zijn.
- Lawine-effect verwachten. Een CRC is lineair: verwante berichten geven verwante CRC's. Prima voor ruis, verkeerd voor hashing — voor bucketing is CRC-64 of een echte hash veiliger dan CRC-32.
- Hex-tekst versus bytes. De string
"123456789" (9 ASCII-bytes, 31 32 33 34 35 36 37 38 39) en het getal 0x123456789 zijn verschillende invoeren met verschillende CRC's. Gebruik het tabblad Hexbytes wanneer uw bronnen werkelijk binair zijn.
Veelgestelde vragen
Waarom komt mijn CRC-32 niet overeen met die in het ZIP-bestand? De CRC-32 van ZIP is ISO-HDLC over de ongecomprimeerde gegevens. Zorg dat u dezelfde bytes hebt gehasht (niet de gecomprimeerde stroom), dezelfde modus (Tekst of Hex) en dezelfde parameterset — de parameterregel onder elk resultaat is er om die controle direct mogelijk te maken.
Welke is beter, CRC-32C of CRC-32? Voor het detecteren van toevallige fouten vangen beide alle bursts tot 32 bits; CRC-32C presteert beter bij sommige foutpatronen en is de variant met CPU-instructies — praktisch gratis bij gigabitsnelheden. De reden dat CRC-32/ISO-HDLC blijft bestaan is compatibiliteit: dertig jaar aan archieven spreekt die taal.
Is CRC-64 sterker dan CRC-32? Het detecteert langere bursts (tot 64 bits) en botst veel minder bij bucketing, maar is even vervalsbaar — breedte levert detectiegaranties, geen beveiliging.
Kan een CRC worden omgekeerd om de invoer te onthullen? Nee — oneindig veel invoeren delen een CRC. Maar anders dan een cryptografische hash kan een aanvaller een invoer construeren met elke gewenste CRC, en in die zin is hij helemaal niet eenrichtings.
