Les lignes ont la forme « ALGORITHME valeur » suivie d’une ligne de paramètres en retrait, de sorte qu’un résultat copié-collé indique toujours le jeu de paramètres qui l’a produit.
CRC — le contrôle de redondance cyclique, expliqué depuis zéro
En une phrase : un CRC traite vos données comme un nombre binaire gigantesque, le divise par un « nombre générateur » fixe en utilisant XOR à la place de la soustraction, et renvoie le reste — une empreinte compacte qui change radicalement dès qu’un seul bit de l’entrée est modifié, ce qui explique pourquoi tout, des fichiers PNG aux lignes Modbus, en porte un.
Ce qu’est réellement un CRC
L’image de la division. Alignez vos octets comme un seul long nombre binaire. Choisissez un diviseur — le polynôme, par ex. 0x04C11DB7 pour CRC-32. Effectuez une division binaire longue où la « soustraction » est l’opération XOR : chaque fois que le bit de tête du reste courant vaut 1, faites un XOR avec le diviseur, décalez vers la gauche, et répétez. Une fois le message entier passé, ce qui reste dans le registre est le CRC. Pas de clés, pas de tables dans la définition — seulement une division avec reste.
Les cinq paramètres. Deux systèmes peuvent tous deux dire « CRC-32 » et pourtant diverger, car le nom seul ne fixe rien. La recette complète nécessite cinq valeurs : poly (le diviseur), init (la valeur initiale du registre — le tout à zéro fait disparaître les zéros de tête, le tout à un ne le fait pas), refin/refout (si chaque octet d’entrée — et le registre final — est inversé bit à bit, héritage du matériel série qui envoyait les bits du moins au plus significatif), et xorout (un masque XOR final, afin qu’une suite de zéros en fin de message change tout de même le résultat). Cette page affiche les cinq valeurs à côté de chaque résultat pour exactement cette raison.
Pourquoi il détecte les erreurs. Un diviseur bien choisi fait différer, avec une probabilité écrasante, le reste d’un message et celui du même message avec quelques bits retournés : un bon CRC-32 détecte toutes les erreurs d’un et de deux bits, tous les nombres impairs d’erreurs de bits, et toute rafale de 32 bits consécutifs corrompus — garanti, et non probabiliste. Cette garantie concerne la corruption accidentelle, et c’est ce qui fait des CRC l’outil adapté aux liaisons bruyantes et aux disques capricieux.
Ce qu’un CRC n’est pas
Ce n’est pas un hachage cryptographique. Il n’y a ni secret ni sens unique : quiconque connaît les paramètres peut forger un message ayant le CRC qu’il veut, en quelques millisecondes, en ajoutant quatre octets correcteurs. Un CRC détecte les accidents, jamais les adversaires. Pour les téléchargements que vous vérifiez auprès d’inconnus, les signatures comptent — voir plutôt le Générateur de hachage (MD5/SHA/BLAKE2). Cette page explique aussi pourquoi MD5 et SHA-1 sont écartés dans des contextes hostiles, alors que SHA-256 tient bon.
Ce n’est pas un code correcteur. Un CRC vous dit que quelque chose a changé, pas quoi a changé. Réparer les erreurs à la volée relève de codes comme Reed–Solomon ou Hamming, qui stockent délibérément une structure redondante qu’un décodeur peut inverser.
Ni compression ni chiffrement. Le reste fait quelques octets quelle que soit la taille de l’entrée, et l’on ne peut pas retrouver l’entrée à partir de lui — mais contrairement à un hachage cryptographique, c’est simplement parce que de l’information a été jetée, et non parce que l’inversion est difficile.
Les familles présentes sur cette page
Les quadruplets CRC-32. Quatre entrées de cette page partagent le polynôme 0x04C11DB7 et produisent pourtant des valeurs différentes : ISO-HDLC (réfléchi, init/xorout à tous à un) est « le » CRC-32 de zlib, gzip, PNG et ZIP ; BZIP2 est le même calcul non réfléchi ; MPEG-2 est BZIP2 sans XOR final ; POSIX part de zéro et sert de base à la commande cksum (qui ajoute en plus la longueur du fichier à la division, de sorte que le cksum d’un fichier et le CRC-32/POSIX des mêmes octets diffèrent). CRC-32C (Castagnoli, polynôme 0x1EDC6F41) est le cinquième frère : un autre polynôme, choisi pour de meilleures performances de détection d’erreurs, et celui que les processeurs x86 et ARM modernes savent calculer à la vitesse de la mémoire en une seule instruction.
Le quatuor CRC-64. XZ utilise le polynôme ECMA-182 sous forme réfléchie avec init et xorout à tous à un ; ECMA-182 lui-même est l’original non réfléchi à init zéro de la norme de bande DLT-1 ; GO-ISO est crc64.ISO de Go, un polynôme minuscule 0x1B, toujours réfléchi ; REDIS utilise un polynôme choisi pour un bon effet d’avalanche dans l’attribution des emplacements de hachage. Soixante-quatre bits est la taille à partir de laquelle les CRC commencent à servir de fonctions de hachage (répartition en seaux) plutôt que de simples sommes de contrôle.
Adler-32 est l’intrus : ce n’est pas une division du tout. Il additionne les octets (A, à partir de 1) et additionne ces sommes (B), les deux modulo 65521, puis concatène les deux sommes de 16 bits. Il est plus rapide que CRC-32 en logiciel, et zlib l’utilise pour les flux deflate — mais pour les entrées courtes (quelques centaines d’octets), la somme porte trop peu d’information, ce qui explique précisément pourquoi zlib repasse à CRC-32 pour les petits blocs.
CRC-8 et CRC-16 subsistent là où les octets coûtent cher : CRC-8/CCITT (polynôme 0x07) protège les octets d’en-tête isolés dans les protocoles SMBus et radio cellulaire ; CRC-16/CCITT-FALSE protège les blocs des cartes à puce ; CRC-16/MODBUS est la somme de contrôle de chaque trame Modbus RTU sur les chaînes de production du monde entier.
Où chacun est utilisé
| Jeu de paramètres | Présent dans |
|---|
| CRC-32/ISO-HDLC | zlib, gzip, PNG, ZIP, Ethernet (FCS), nombreux formats d’archive |
| CRC-32C | iSCSI, ext4, btrfs, ZFS, instruction matérielle CRC32C de SSE4.2/ARMv8 |
| CRC-32/BZIP2 | Flux d’archive .bz2 |
| CRC-32/MPEG-2 | Flux de transport MPEG-2 |
| CRC-32/POSIX & cksum | Sortie de la commande POSIX cksum (cksum file.txt) |
| CRC-16/MODBUS | Trames Modbus RTU (automates industriels, compteurs, onduleurs) |
| CRC-16/CCITT-FALSE | Cartes à puce, liaisons voisines de X.25, certains protocoles GPS |
| CRC-8/CCITT | SMBus (octet PEC), en-têtes radio cellulaires |
| CRC-64/XZ | Contrôles d’intégrité du conteneur .xz |
| CRC-64/ECMA-182 | ECMA-182 / norme de bande DLT-1 |
| CRC-64/GO-ISO | Bibliothèque standard de Go crc64.ISO |
| CRC-64/REDIS | Attribution des emplacements de hachage du cluster Redis |
| Adler-32 | Flux zlib (deflate), autres contextes de somme rapide |
La table d’ancrage — check(“123456789”)
La convention du catalogue CRC consiste à publier le résultat pour la chaîne ASCII 123456789 (9 octets). Chaque valeur ci-dessous est reproductible sur cette page : saisissez 123456789 dans la zone Texte, cochez l’algorithme, puis cliquez sur Calculer.
| Jeu de paramètres | Largeur | Valeur de contrôle (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 |
Sources : chaque valeur a été recoupée par une implémentation de référence bit à bit indépendante et, lorsqu’elle existe, par la bibliothèque système qui fournit l’algorithme (zlib pour CRC-32 et Adler-32 ; le catalogue CRC de Greg Cook pour le reste).
Erreurs courantes
- « CRC-32 » sans paramètres. Entre ISO-HDLC, BZIP2, MPEG-2, POSIX et CRC-32C, cinq valeurs différentes circulent sous le même nom. Consignez toujours poly/init/refin/refout/xorout avec le résultat — cette page les affiche pour vous.
- Comparer le CRC-32 d’un fichier avec sa sortie
cksum. Algorithmes différents : cksum ajoute la longueur et utilise un init différent. Les nombres ne correspondront pas, et les deux sont « justes ».
- Faire confiance au CRC contre la falsification. Forger un CRC identique est un exercice classique (corriger les 4 derniers octets). Utilisez un MAC à clé (HMAC) ou une signature lorsque l’autre partie peut être malveillante.
- S’attendre à un effet d’avalanche. Un CRC est linéaire : des messages liés donnent des CRC liés. Acceptable contre le bruit, inadapté au hachage — si vous avez besoin de répartir en seaux, CRC-64 ou un vrai hachage est plus sûr que CRC-32.
- Texte hexadécimal ou octets. La chaîne
"123456789" (9 octets ASCII, 31 32 33 34 35 36 37 38 39) et le nombre 0x123456789 sont des entrées différentes aux CRC différents. Utilisez l’onglet Octets hexadécimaux lorsque vos données source sont réellement binaires.
FAQ
Pourquoi mon CRC-32 ne correspond-il pas à celui du fichier ZIP ? Le CRC-32 de ZIP est ISO-HDLC appliqué aux données non compressées. Assurez-vous d’avoir haché les mêmes octets (et non le flux compressé), le même mode (Texte ou Hex) et le même jeu de paramètres — la ligne de paramètres affichée sous chaque résultat sert précisément à effectuer cette vérification instantanément.
Lequel est préférable, CRC-32C ou CRC-32 ? Pour la détection d’erreurs accidentelles, les deux détectent toutes les rafales jusqu’à 32 bits ; CRC-32C se comporte mieux sur certains schémas d’erreurs et bénéficie d’instructions processeur — pratiquement gratuit aux débits gigabit. Si CRC-32/ISO-HDLC perdure, c’est pour la compatibilité : trente ans d’archives le parlent.
CRC-64 est-il plus solide que CRC-32 ? Il détecte des rafales plus longues (jusqu’à 64 bits) et entre en collision bien moins souvent lorsqu’il sert à répartir en seaux, mais il est tout aussi falsifiable — la largeur apporte des garanties de détection, et non de la sécurité.
Un CRC peut-il être inversé pour révéler l’entrée ? Non — une infinité d’entrées partagent un même CRC. Mais contrairement à un hachage cryptographique, un attaquant peut construire une entrée ayant le CRC qu’il choisit, ce qui signifie qu’il n’est pas à sens unique du tout.
