Calculateur CRC-32 - Somme de contrôle de texte et fichiers

Le CRC-32 est utilisé partout où une vérification bon marché et quasi certaine contre la corruption accidentelle vaut mieux qu'une garantie de sécurité. Chaque archive ZIP en stocke une par entrée dans son répertoire central, et unzip la vérifie à l'extraction : un fichier tronqué ou dont des bits ont changé est signalé au lieu de produire silencieusement n'importe quoi. gzip et zlib ajoutent un CRC-32 à la fin de leur flux compressé, et c'est pourquoi un fichier .gz corrompu produit une erreur de somme de contrôle plutôt qu'une inexplicable erreur de décompression. Le PNG range un CRC-32 dans chaque fragment, ce qui permet à la fois de valider chaque bloc indépendamment et d'arrêter le décodeur au premier fragment douteux. Les flux de transport MPEG-2 en portent un par paquet, et la séquence de contrôle de trame d'Ethernet est un CRC-32 calculé par le matériel de la carte réseau sur chaque trame qui traverse un commutateur. Dans tous ces cas le modèle de menace est le même : bruit, vieillissement, écritures partielles et versions divergentes, et non un attaquant déterminé.

Non, et s'en servir pour des mots de passe ou pour vérifier l'intégrité d'un téléchargement provenant d'une source non fiable serait une grave erreur. Un CRC est une fonction linéaire sur le corps GF(2), ce qui signifie qu'appliquer le même OU exclusif à deux messages produit la même différence entre leurs sommes. Quiconque connaît un message et sa somme peut donc construire un autre message, différent de quatre octets au plus, portant la somme de son choix. C'est une falsification qui ne demande ni ingenuity ni recherche. Avec seulement 32 bits de largeur, un attaquant peut précalculer une collision en quelques secondes sur GPU. Il n'a ni clé, ni sel, ni facteur de coût, ni comportement en avalanche, et ne fournit donc aucune des propriétés d'irréversibilité, d'imprévisibilité ou de résistance à la recherche exhaustive dont dépendent le stockage de mots de passe et la signature de code. Utilisez un hachage cryptographique comme SHA-256 pour l'intégrité face à un adversaire, et une fonction spécialisée comme Argon2id ou bcrypt pour tout ce qui ressemble à un identifiant.

Parce que ces deux noms désignent le même algorithme enveloppé dans des cadrages légèrement différents. La ligne CRC-32b de ce calculateur exécute l'algorithme identique sur vos octets augmentés d'un octet 0x00 final, et cet octet supplémentaire modifie l'état du registre, si bien que toutes les valeurs sont décalées. L'intérêt d'une telle variante est de distinguer la charge de son propre terminateur, afin qu'un flux qui se termine légitimement par un octet nul ne soit pas confondu avec un autre qui s'y termine par accident. Sachez que le terme est employé de façon incohérente : la variante BZIP2, habituellement notée CRC-32/BZIP2 et identifiée par la valeur de contrôle 0xCBF43926 pour la chaîne 123456789, ajoute quatre octets nuls et non un, et constitue une fonction différente. Si vous dialoguez avec un outil ou un format précis, vérifiez ce que cette implémentation ajoute réellement plutôt que de vous fier au nom.

C'est la forme inversée du polynôme générateur du CRC-32, 0x04C11DB7, et elle apparaît dans pratiquement toutes les implémentations logicielles de CRC-32 que vous croiserez. Le polynôme générateur définit quels motifs de bits sont considérés comme des erreurs. Sa forme normale, bits dans l'ordre direct, est celle des manuels, mais l'ordre inversé permet d'exécuter tout le calcul de droite à gauche à travers les octets, ce qui exige une consultation de table et un décalage par octet au lieu de huit décalages conditionnels. Dans l'implémentation inversée, la valeur 0x04C11DB7 devient 0xEDB88320, et chacune des 256 entrées de la table s'obtient en partant de la valeur d'un octet et en appliquant huit fois la boucle d'inversion : si le bit de poids faible est à un, on fait l'OU exclusif avec 0xEDB88320 puis on décale à droite, sinon on décale simplement à droite. Construire la table à partir de cette définition, comme le fait cet outil, est plus sûr que coller un tableau de 256 entrées, car cela élimine tout risque que la table livrée dérive de la définition qu'elle prétend implémenter.

Parce que l'espace de sortie ne fait que 32 bits : il y a environ 4,3 milliards de sommes possibles à partager entre tous les messages possibles, et il est inévitable que certains messages en partagent une. En appliquant le principe des tiroirs, le nombre de messages nécessaires pour qu'une collision devienne probable est approximativement la racine carrée de 2^32, soit environ 65536 : des données aléatoires produisent donc un CRC en double dans cette zone. Les fichiers réels sont moins favorables que l'aléatoire, car des documents structurés ne diffèrent souvent que sur quelques emplacements prévisibles. Ce n'est pas un défaut de conception, c'est la conception qui fonctionne comme prévu. Un CRC-32 détecte avec certitude toute erreur sur un seul bit et toute erreur en salve jusqu'à 32 bits, ce qui couvre pratiquement toute la corruption accidentelle due au bruit, au vieillissement et aux pannes de transfert. Ce qu'il ne peut pas faire, c'est établir une identité face à un adversaire, car un adversaire peut construire une collision délibérément en quelques secondes. Si vous avez besoin de résistance aux collisions, il vous faut un hachage cryptographique.

Calculez le CRC-32 du fichier ici et comparez-le à la somme de contrôle enregistrée par l'éditeur ou par le système de transfert. S'ils concordent, le fichier est arrivé sans corruption. Beaucoup d'outils le font déjà pour vous : unzip vérifie chaque entrée, gzip et zlib vérifient la fin du flux, et les navigateurs vérifient les fragments PNG au décodage. Mais calculer la valeur soi-même reste le moyen le plus rapide de confirmer ce qu'un outil donné a produit, et c'est le seul moyen lorsque vous avez un format inhabituel sans vérification intégrée. Choisissez le mode File, sélectionnez le téléchargement et lisez la sortie CRC-32 of file. Une mise en garde importante : une concordance prouve que le fichier est bien celui qu'a produit l'éditeur, à condition que vous fassiez confiance à cet éditeur. Si le téléchargement a pu être altéré en transit, un attaquant disposant de cette capacité peut fabriquer un autre fichier portant la même somme, et c'est précisément pourquoi les publications signées avec GPG ou des signatures Sigstore existent en complément des sommes de contrôle.

Non. Le calculateur est un composant côté client : le JavaScript de votre navigateur lit votre texte, vos octets hexadécimaux ou le fichier que vous avez sélectionné, construit la table CRC-32 en mémoire et exécute la boucle localement. Rien n'est transmis sur le réseau, rien n'est écrit dans un journal de serveur et rien ne persiste après la fermeture de l'onglet. Pour le mode fichier, c'est mis en œuvre avec l'API de fichiers du navigateur, qui lit le fichier du disque local à la demande. L'intérêt est pratique, et pas seulement lié à la vie privée : vous pouvez contrôler une image disque de plusieurs gigaoctets ou une archive confidentielle réglementée sans attendre un envoi et sans remettre une copie de vos données à un service tiers.