Liniile au forma „ALGORITM valoare” urmată de o linie de parametri indentată, astfel încât un rezultat copiat și lipit indică întotdeauna setul de parametri care l-a produs.
CRC — verificarea ciclică a redundanței, explicată de la zero
Într-o propoziție: un CRC tratează datele ca pe un număr binar gigantic, îl împarte la un număr „generator” fix folosind XOR în loc de scădere și raportează restul — o amprentă compactă care se schimbă brusc chiar și când se inversează un singur bit din intrare, de aceea totul, de la fișierele PNG la firele Modbus, poartă unul.
Ce este de fapt un CRC
Imaginea împărțirii. Se aliniază octeții ca un singur număr binar lung. Se alege un divizor — polinomul, de exemplu 0x04C11DB7 pentru CRC-32. Se efectuează împărțirea binară lungă, în care „scăderea” este operația XOR: ori de câte ori bitul din față al restului curent este 1, se face XOR cu divizorul, se deplasează spre stânga și se repetă. După ce tot mesajul a trecut, ce rămâne în registru este CRC-ul. Fără chei, fără tabele în definiție — doar împărțire cu rest.
Cei cinci parametri. Două sisteme pot spune amândouă „CRC-32” și totuși nu se înțeleg, deoarece numele singur nu fixează nimic. Rețeta completă are nevoie de cinci valori: poly (divizorul), init (cu ce pornește registrul — init format din zerouri face ca octeții nuli de la început să nu conteze, iar init format din unu nu), refin/refout (dacă fiecare octet de intrare — și registrul final — este inversat pe biți, o moștenire a hardware-ului serial care trimitea biții începând cu cel mai puțin semnificativ) și xorout (o mască XOR finală, astfel încât o serie de zerouri de la coadă să schimbe în continuare răspunsul). Această pagină tipărește toți cei cinci lângă fiecare rezultat exact din acest motiv.
De ce detectează erori. Un divizor bine ales face ca restul unui mesaj și restul aceluiași mesaj cu câțiva biți cu valoare inversată să difere cu o probabilitate covârșitoare: un CRC-32 bun prinde toate erorile de 1 și de 2 biți, toate numerele impare de erori de biți și orice rafală de până la 32 de biți consecutivi corupți — garantat, nu probabilistic. Această garanție privește corupția accidentală, iar ea face din CRC-uri instrumentul potrivit pentru cabluri zgomotoase și discuri defecte.
Ce nu este un CRC
Nu este un hash criptografic. Nu există secret și nicio unidirecționalitate: oricine cunoaște parametrii poate falsifica un mesaj cu orice CRC dorește, în milisecunde, adăugând patru octeți de corecție. Un CRC detectează accidentele, niciodată adversarii. Pentru descărcări verificate față de necunoscuți contează semnăturile — vezi Generatorul hash (MD5/SHA/BLAKE2). Pagina aceea explică și de ce MD5 și SHA-1 sunt retrase pentru contexte ostile, în timp ce SHA-256 rămâne valabil.
Nu este un cod de corectare a erorilor. Un CRC arată că ceva s-a schimbat, nu ce s-a schimbat. Repararea erorilor din mers este treaba unor coduri precum Reed–Solomon sau Hamming, care stochează deliberat o structură redundantă pe care un decodor o poate inversa.
Nu este compresie și nu este criptare. Restul are câțiva octeți indiferent de dimensiunea intrării, iar din el nu se poate recupera intrarea — dar, spre deosebire de un hash criptografic, asta se întâmplă doar pentru că informația a fost aruncată, nu pentru că inversarea ar fi grea.
Familiile din această pagină
Cvartetul CRC-32. Patru dintre intrările acestei pagini împart polinomul 0x04C11DB7 și totuși produc valori diferite: ISO-HDLC (reflectat, init/xorout formate din unu) este „CRC-32-ul” din zlib, gzip, PNG și ZIP; BZIP2 este aceeași matematică nereflectată; MPEG-2 este BZIP2 fără XOR final; POSIX pornește de la zero și este baza comenzii cksum (care adaugă în plus lungimea fișierului la împărțire, deci cksum al unui fișier și CRC-32/POSIX al acelorași octeți diferă). CRC-32C (Castagnoli, polinomul 0x1EDC6F41) este al cincilea frate: un polinom diferit, ales pentru o performanță mai bună a detectării erorilor, și cel pe care procesoarele moderne x86 și ARM îl pot calcula la viteza memoriei, cu o singură instrucțiune.
Cvartetul CRC-64. XZ folosește polinomul ECMA-182 în formă reflectată, cu init și xorout formate din unu; ECMA-182 în sine este originalul nereflectat, cu init zero, din standardul benzii DLT-1; GO-ISO este crc64.ISO din Go, cu un polinom mic 0x1B, încă reflectat; REDIS folosește un polinom ales pentru un bun efect de avalanșă la atribuirea sloturilor de hash. Șaizeci și patru de biți este dimensiunea la care CRC-urile încep să fie folosite ca funcții hash (împărțire pe categorii), nu ca simple sume de control.
Adler-32 este outsiderul: nu este deloc o împărțire. Însumează octeții (A, pornind de la 1) și însumează aceste sume (B), ambele modulo 65521, și concatenează cele două sume de 16 biți. Este mai rapid decât CRC-32 în software, iar zlib îl folosește pentru fluxurile deflate — dar pentru intrări scurte (sub câteva sute de octeți) suma poartă prea puțină informație, motiv exact pentru care zlib revine la CRC-32 pentru blocuri mici.
CRC-8 și CRC-16 supraviețuiesc acolo unde octeții sunt scumpi: CRC-8/CCITT (polinom 0x07) protejează octeți singulari din antet în SMBus și în protocoalele radiourilor celulare; CRC-16/CCITT-FALSE protejează blocurile cardurilor cu cip; CRC-16/MODBUS este suma de control a fiecărui cadru Modbus RTU din halele de fabrică din întreaga lume.
Unde trăiește fiecare
| Setul de parametri | Se găsește în |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), multe formate de arhivă |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, instrucțiunea hardware CRC32C din SSE4.2/ARMv8 |
| CRC-32/BZIP2 | Flux de arhivă .bz2 |
| CRC-32/MPEG-2 | Fluxuri de transport MPEG-2 |
| CRC-32/POSIX & cksum | Ieșirea comenzii POSIX cksum (cksum file.txt) |
| CRC-16/MODBUS | Cadre Modbus RTU (PLC-uri industriale, contoare, invertoare) |
| CRC-16/CCITT-FALSE | Carduri cu cip, legături apropiate de X.25, unele protocoale GPS |
| CRC-8/CCITT | SMBus (octetul PEC), antete ale radiourilor celulare |
| CRC-64/XZ | Verificări de integritate ale containerului .xz |
| CRC-64/ECMA-182 | ECMA-182 / standardul benzii DLT-1 |
| CRC-64/GO-ISO | Biblioteca standard Go crc64.ISO |
| CRC-64/REDIS | Atribuirea sloturilor de hash din clusterul Redis |
| Adler-32 | Fluxuri zlib (deflate), alte contexte cu sumă de control rapidă |
Tabelul de ancorare — check(„123456789”)
Convenția catalogului CRC este să se publice rezultatul pentru șirul ASCII 123456789 (9 octeți). Fiecare valoare de mai jos poate fi reprodusă pe această pagină: se scrie 123456789 în caseta Text, se bifează algoritmul și se apasă Calculare.
| Setul de parametri | Lățime | Valoarea de verificare (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 |
Surse: fiecare valoare a fost verificată încrucișat cu o implementare bit cu bit independentă de referință și, acolo unde există, cu biblioteca de sistem care livrează algoritmul (zlib pentru CRC-32 și Adler-32; catalogul CRC al lui Greg Cook pentru restul).
Greșeli frecvente
- „CRC-32” fără parametri. Între ISO-HDLC, BZIP2, MPEG-2, POSIX și CRC-32C circulă cinci valori diferite sub același nume. Se notează întotdeauna poly/init/refin/refout/xorout împreună cu rezultatul — această pagină le tipărește automat.
- Compararea CRC-32 al unui fișier cu ieșirea
cksum. Algoritmi diferiți: cksum adaugă lungimea și folosește un init diferit. Numerele nu vor coincide, iar ambele sunt „corecte”.
- Încrederea în CRC împotriva manipulării. Falsificarea unui CRC care se potrivește este un exercițiu clasic (se modifică ultimii 4 octeți). Se folosește un MAC cu cheie (HMAC) sau o semnătură atunci când cealaltă parte ar putea fi ostilă.
- Așteptarea efectului de avalanșă. Un CRC este liniar: mesajele înrudite dau CRC-uri înrudite. Potrivit pentru zgomot, nepotrivit pentru hashing — dacă este nevoie de împărțire pe categorii, CRC-64 sau un hash real este mai sigur decât CRC-32.
- Text hexazecimal față de octeți. Șirul
"123456789" (9 octeți ASCII, 31 32 33 34 35 36 37 38 39) și numărul 0x123456789 sunt intrări diferite, cu CRC-uri diferite. Se folosește fila Octeți hexazecimali atunci când datele sursă sunt cu adevărat binare.
Întrebări frecvente
De ce nu se potrivește CRC-32-ul cu cel din fișierul ZIP? CRC-32 din ZIP este ISO-HDLC peste datele necomprimate. Se verifică dacă s-au calculat hash-urile acelorași octeți (nu fluxul comprimat), același mod (text sau hexazecimal) și același set de parametri — linia cu parametri tipărită sub fiecare rezultat există tocmai pentru ca verificarea să fie imediată.
Care este mai bun, CRC-32C sau CRC-32? Pentru detectarea erorilor accidentale, ambele prind toate rafalele de până la 32 de biți; CRC-32C performează mai bine pe unele tipare de erori și are instrucțiuni dedicate în procesor — efectiv gratuit la viteze de gigabit. Motivul pentru care CRC-32/ISO-HDLC supraviețuiește este compatibilitatea: treizeci de ani de arhive îl vorbesc.
Este CRC-64 mai puternic decât CRC-32? Detectează rafale mai lungi (până la 64 de biți) și se ciocnește mult mai rar când este folosit pentru împărțirea pe categorii, dar este la fel de ușor de falsificat — lățimea aduce garanții de detectare, nu securitate.
Poate fi inversat un CRC pentru a dezvălui intrarea? Nu — infinit de multe intrări au același CRC. Dar, spre deosebire de un hash criptografic, un atacator poate construi o intrare cu orice CRC dorește, ceea ce înseamnă că nu este deloc unidirecțional.
