Raderna använder formen “ALGORITM värde” följt av en indragen parameterrad, så att ett inklistrat resultat alltid säger vilken parameteruppsättning som producerade det.
CRC — cyklisk redundanskontroll, förklarad från grunden
I en mening: en CRC behandlar data som ett enormt binärt tal, dividerar det med ett fast “generator”-tal med XOR i stället för subtraktion, och rapporterar resten — ett kompakt fingeravtryck som förändras kraftigt även när en enda bit i indatan vänds, vilket är varför allt från PNG-filer till Modbus-ledningar bär en.
Vad en CRC faktiskt är
: Divisionsbilden. Ställ upp byten som ett enda långt binärt tal. Välj en divisor — polynomet, t.ex. 0x04C11DB7 för CRC-32. Utför binär långdivision där “subtraktion” är XOR-operationen: närhelst den ledande biten i den löpande resten är 1, XOR:a in divisorn, skifta vänster och upprepa. När hela meddelandet har gått igenom är det som återstår i registret CRC:n. Inga nycklar, inga tabeller i definitionen — bara division med en rest.
De fem parametrarna. Två system kan båda säga “CRC-32” och ändå inte vara överens, eftersom namnet ensamt inte fixerar något. Det fullständiga receptet behöver fem värden: poly (divisorn), init (vad registret börjar som — nollställt låter inledande nollbyte försvinna, ettställt gör det inte), refin/refout (om varje indatabyte — och det slutliga registret — är bitvänt, en arv från seriell hårdvara som skickade bitar minst signifikant först), och xorout (en slutlig XOR-mask så att en rad avslutande nollor fortfarande ändrar svaret). Den här sidan skriver ut alla fem bredvid varje resultat av just den anledningen.
Varför den upptäcker fel. En väl vald divisor gör att resten av ett meddelande och resten av samma meddelande med några vända bitar skiljer sig med överväldigande sannolikhet: en bra CRC-32 fångar alla 1-bitars och 2-bitars fel, alla udda antal bitfel och varje skur om upp till 32 på varandra följande skadade bitar — garanterat, inte probabilistiskt. Den garantin gäller oavsiktlig korruption, och det är vad som gör CRC:er till rätt verktyg för brusiga ledningar och skörda diskar.
Vad en CRC inte är
Inte en kryptografisk hash. Det finns ingen hemlighet och ingen envägsegenskap: vem som helst som känner parametrarna kan förfalska ett meddelande med vilken CRC de vill, på millisekunder, genom att lägga till fyra korrigerande byte. En CRC upptäcker olyckor, aldrig motståndare. För nedladdningar som verifieras mot okända parter spelar signaturer roll — se i stället Hashgeneratorn (MD5/SHA/BLAKE2). Den sidan förklarar också varför MD5 och SHA-1 är utrangerade för fientliga miljöer medan SHA-256 står sig.
Inte en felrättande kod. En CRC talar om att något ändrats, inte vad som ändrats. Att reparera fel i farten är uppgiften för koder som Reed–Solomon eller Hamming, som medvetet lagrar redundant struktur som en avkodare kan invertera.
Inte komprimering eller kryptering. Resten är några byte oavsett indatastorlek, och från den kan man inte återskapa indata — men till skillnad från en kryptografisk hash beror det bara på att information kasserats, inte på att inversionen är svår.
Familjerna på den här sidan
CRC-32-kvadrupletten. Fyra av sidans poster delar polynomet 0x04C11DB7 och ger ändå olika värden: ISO-HDLC (reflekterad, init/xorout ettställda) är “den” CRC-32 i zlib, gzip, PNG och ZIP; BZIP2 är samma matematik oreflekterad; MPEG-2 är BZIP2 utan någon slutlig XOR; POSIX börjar från noll och är grunden för kommandot cksum (som dessutom lägger till filens längd till divisionen, så cksum för en fil och CRC-32/POSIX för samma byte skiljer sig). CRC-32C (Castagnoli, poly 0x1EDC6F41) är den femte syskonet: ett annat poly valt för bättre felupptäcktsprestanda, och det som moderna x86- och ARM-processorer kan beräkna i minneshastighet med en enda instruktion.
CRC-64-kvartetten. XZ använder ECMA-182-polynomet i reflekterad form med ettställd init och xorout; ECMA-182 själv är den oreflekterade originalvarianten med noll-init från DLT-1-bandstandarden; GO-ISO är Gos crc64.ISO, ett litet poly 0x1B, fortfarande reflekterat; REDIS använder ett poly valt för god lavineffekt vid tilldelning av hash-platser. Sextiofyra bitar är storleken där CRC:er börjar användas som hashfunktioner (hinkfördelning) snarare än rena kontrollsummor.
Adler-32 är utomstående: den är inte alls en division. Den summerar byten (A, med start på 1) och summerar dessa summor (B), båda modulo 65521, och sammanfogar de två 16-bitarssummorna. Den är snabbare än CRC-32 i programvara och zlib använder den för deflate-strömmar — men för korta indata (under några hundra byte) bär summan för lite information, vilket är exakt varför zlib byter tillbaka till CRC-32 för små block.
CRC-8 och CRC-16 överlever där byte är dyra: CRC-8/CCITT (poly 0x07) skyddar enstaka headerbyte i SMBus- och mobilradioprotokoll; CRC-16/CCITT-FALSE skyddar chipkortsblock; CRC-16/MODBUS är kontrollsumman för varje Modbus RTU-ram i fabriker världen över.
Var var och en används
| Parameteruppsättning | Finns i |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), många arkivformat |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, SSE4.2/ARMv8 hårdvaruinstruktionen CRC32C |
| CRC-32/BZIP2 | Strömmen i .bz2-arkiv |
| CRC-32/MPEG-2 | MPEG-2-transportströmmar |
| CRC-32/POSIX & cksum | Utdata från POSIX-kommandot cksum (cksum file.txt) |
| CRC-16/MODBUS | Modbus RTU-ramar (industriella PLC:er, mätare, växelriktare) |
| CRC-16/CCITT-FALSE | chipkort, länkar nära X.25, vissa GPS-protokoll |
| CRC-8/CCITT | SMBus (PEC-byte), mobilradiohuvuden |
| CRC-64/XZ | Integritetskontroller i .xz-behållare |
| CRC-64/ECMA-182 | ECMA-182 / DLT-1-bandstandarden |
| CRC-64/GO-ISO | Gos standardbibliotek crc64.ISO |
| CRC-64/REDIS | Tilldelning av hash-platser i Redis-kluster |
| Adler-32 | zlib-strömmar (deflate), andra sammanhang med snabb kontrollsumma |
Förankringstabellen — check(“123456789”)
CRC-kataloget publicerar konventionellt resultatet för ASCII-strängen 123456789 (9 byte). Varje värde nedan kan återskapas på den här sidan: skriv 123456789 i textrutan, markera algoritmen och klicka på Beräkna.
| Parameteruppsättning | Bredd | Kontrollvärde (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 |
Källor: varje värde har korskontrollerats med en oberoende bitvis referensimplementering och, där en sådan finns, mot systembiblioteket som levererar algoritmen (zlib för CRC-32 och Adler-32; CRC Greg Cook-katalogen för resten).
Vanliga misstag
- “CRC-32” utan parametrar. Mellan ISO-HDLC, BZIP2, MPEG-2, POSIX och CRC-32C cirkulerar fem olika värden under samma namn. Spara alltid poly/init/refin/refout/xorout tillsammans med resultatet — den här sidan skriver ut dem automatiskt.
- Att jämföra en fils CRC-32 med dess
cksum-utdata. Olika algoritmer: cksum lägger till längden och använder en annan init. Talen stämmer inte överens, och båda är “rätt”.
- Att lita på CRC mot manipulation. Att förfalska en matchande CRC är en klassisk övning (patcha de sista 4 byten). Använd en nyckelad MAC (HMAC) eller en signatur när den andra parten kan vara fientlig.
- Att förvänta sig lavineffekt. En CRC är linjär: närbesläktade meddelanden ger närbesläktade CRC:er. Bra för brus, fel för hashning — om hinkfördelning behövs är CRC-64 eller en riktig hash säkrare än CRC-32.
- Hextext kontra byte. Strängen
"123456789" (9 ASCII-byte, 31 32 33 34 35 36 37 38 39) och talet 0x123456789 är olika indata med olika CRC:er. Använd fliken Hexbyte när källdatan verkligen är binär.
Vanliga frågor
Varför stämmer inte min CRC-32 med den i ZIP-filen? ZIP:s CRC-32 är ISO-HDLC över de okomprimerade data. Kontrollera att samma byte hashats (inte den komprimerade strömmen), samma läge (Text eller Hex) och samma parameteruppsättning — parameterraden som skrivs ut under varje resultat finns där för att göra den kontrollen omedelbar.
Vilken är bättre, CRC-32C eller CRC-32? För upptäckt av oavsiktliga fel fångar båda alla skurar upp till 32 bitar; CRC-32C presterar bättre för vissa felmönster och är den som har processorinstruktioner — i praktiken gratis vid gigabithastigheter. Anledningen till att CRC-32/ISO-HDLC överlever är kompatibilitet: trettio års arkiv talar den.
Är CRC-64 starkare än CRC-32? Den upptäcker längre skurar (upp till 64 bitar) och kolliderar betydligt mindre vid hinkfördelning, men den är lika lätt att förfalska — bredd ger upptäcktsgarantier, inte säkerhet.
Kan en CRC vändas för att avslöja indata? Nej — oändligt många indata delar en CRC. Men till skillnad från en kryptografisk hash kan en angripare konstruera en indata med vilken CRC som helst, vilket är i vilken mening den inte alls är envägs.
