Calculer le checksum d'un fichier

Un checksum (somme de contrôle, parfois orthographié chksum) est une empreinte numérique unique calculée à partir du contenu d'un fichier par un algorithme de hachage. Cette empreinte, ou fingerprint, est généralement représentée par une chaîne hexadécimale de longueur fixe.

La propriété fondamentale d'un bon algorithme de hachage est l'effet d'avalanche : toute modification du fichier source, même d'un seul bit, produit un checksum radicalement différent. Deux fichiers de contenu strictement identique produisent toujours le même checksum, indépendamment du nom de fichier, de la date de modification ou du système d'exploitation.

Le checksum sert principalement à vérifier l'intégrité d'un fichier : si l'empreinte recalculée localement correspond à celle annoncée par l'éditeur, le fichier est intact. Sinon, il a été altéré, corrompu en transit, ou modifié.

• Vérifier l'intégrité d'un téléchargement : une ISO Linux (Debian, Ubuntu, Fedora, Arch), une image Docker, un installeur Windows ou une archive open source publient systématiquement un checksum officiel. Le recalculer localement confirme que le fichier est complet et non altéré.
• Détecter une corruption en transit : un téléchargement coupé, un secteur disque défaillant, une RAM instable, un câble réseau capricieux, ou une copie sur clé USB peuvent corrompre des octets. Le checksum révèle immédiatement ces erreurs silencieuses.
• Empreinte de signature : confirmer qu'un fichier provient bien de l'auteur attendu lorsque le checksum est diffusé via un canal sûr (HTTPS, signature GPG). C'est le mécanisme à la base des dépôts de paquets Linux et des magasins d'applications.
• Versionning et caching : Git identifie chaque commit, blob et arbre par un hash SHA-1 (en migration vers SHA-256). Les CDN et bundlers web (Webpack, Vite, esbuild) injectent un hash dans le nom de fichier (app.4a8f2c.js) pour invalider automatiquement le cache navigateur lors d'un changement.
• Détection de duplicatas et déduplication : sauvegardes incrémentales (Borg, Restic, rsync), systèmes de fichiers (ZFS), et stockages objet identifient les blocs identiques par leur hash pour ne stocker qu'une seule copie.
• Validation d'upload : un client envoie le checksum attendu, le serveur le recalcule à réception. AWS S3, par exemple, accepte un en-tête Content-MD5 ou x-amz-checksum-sha256 pour rejeter un upload corrompu.
• Threat intelligence et antivirus : VirusTotal et les éditeurs antivirus indexent les fichiers malveillants par leur hash SHA-256, ce qui permet une détection sans transmettre le binaire complet.

• MD5 (128 bits, 32 caractères hexadécimaux) : rapide, largement diffusé, mais cassé cryptographiquement. Des collisions MD5 sont calculables en quelques secondes sur du matériel courant depuis 2004. À utiliser uniquement pour la vérification d'intégrité non malveillante (téléchargement contre une coupure réseau, sauvegarde locale). Proscrit pour toute fonction de sécurité, signature, ou authentification.
• SHA-1 (160 bits, 40 caractères hexadécimaux) : déprécié pour la cryptographie depuis l'attaque SHAttered de 2017, qui a démontré une collision réelle entre deux PDF distincts. Git l'utilise toujours par défaut mais migre vers SHA-256. Ne plus l'utiliser pour signer ou authentifier.
• SHA-256 (256 bits, 64 caractères hexadécimaux) : standard moderne, membre de la famille SHA-2. Base des certificats TLS modernes, des signatures de paquets Linux (apt, dnf, pacman), de Bitcoin, et des contrôles d'intégrité officiels. Plus lent que MD5 mais sûr en l'état des connaissances actuelles.
• SHA-512 (512 bits, 128 caractères hexadécimaux) : variante 64-bit de SHA-2. Manipule des mots de 64 bits nativement, ce qui le rend parfois plus rapide que SHA-256 sur CPU 64-bit. Empreinte plus longue, marge de sécurité supérieure.
• CRC32 (32 bits, 8 caractères hexadécimaux) : non cryptographique, ultra-rapide, conçu spécifiquement pour détecter les erreurs de transmission. Utilisé par Ethernet, ZIP, PNG, gzip. Ne protège pas contre la malveillance : un attaquant peut trivialement forger un fichier avec le même CRC32 qu'un autre. Adapté aux contrôles matériels rapides, pas à la sécurité.

• Vérifier une ISO Linux : Debian, Ubuntu, Fedora et Arch publient les SHA-256 et SHA-512 de chaque image officielle, souvent contresignés en GPG.
• Valider un binaire signé : confirmer qu'un exécutable téléchargé depuis un miroir n'a pas été remplacé par une version piégée.
• Comparer deux versions : avant et après une modification, un checksum identique prouve l'identité bit à bit, sans avoir à diffuser les fichiers.
• Validation d'upload : le client envoie un checksum, le serveur le recalcule à réception pour confirmer l'absence de corruption.
• Fingerprinting : détection de bots ou de fichiers connus dans des bases d'empreintes (antivirus, threat intelligence, recherche de doublons).

1. Glissez-déposez le fichier dans la zone prévue, ou utilisez le bouton de sélection.
2. Choisissez l'algorithme : MD5, SHA-1, SHA-256, SHA-512 ou CRC32.
3. Le checksum s'affiche, prêt à être copié.
4. Comparez la valeur obtenue avec celle de référence (publiée par l'éditeur ou conservée localement).

Le calcul se fait localement dans votre navigateur, sans envoi du fichier sur un serveur distant. Le contenu reste confidentiel.

La procédure standard de vérification est la suivante :

1. Le site officiel publie le checksum attendu, par exemple d41d8cd98f00b204e9800998ecf8427e pour MD5 ou une chaîne de 64 caractères pour SHA-256.
2. Téléchargez le fichier.
3. Calculez son checksum, soit avec cet outil, soit en ligne de commande.
4. Comparez : si les deux chaînes sont strictement identiques, caractère par caractère, le fichier est intact. Si elles diffèrent, même d'un seul caractère, le fichier est corrompu ou trafiqué : ne l'utilisez pas, retéléchargez-le.

En ligne de commande sous Linux :

# Calculer le checksum
md5sum fichier.iso
sha1sum fichier.iso
sha256sum fichier.iso
sha512sum fichier.iso
cksum fichier.iso          # CRC32 + taille

# Vérifier automatiquement depuis un fichier .sha256 publié par l'éditeur
sha256sum -c fichier.iso.sha256
# Affiche : "fichier.iso: OK" si le checksum correspond

Sous macOS :

md5 fichier.iso
shasum -a 1 fichier.iso
shasum -a 256 fichier.iso
shasum -a 512 fichier.iso

# Vérification depuis un fichier de référence
shasum -a 256 -c fichier.iso.sha256

Sous Windows (PowerShell) :

Get-FileHash fichier.iso -Algorithm MD5
Get-FileHash fichier.iso -Algorithm SHA1
Get-FileHash fichier.iso -Algorithm SHA256
Get-FileHash fichier.iso -Algorithm SHA512

# Comparer à une valeur attendue
(Get-FileHash fichier.iso -Algorithm SHA256).Hash -eq "ABC123..."

Algorithme	Taille	Vitesse	Usage recommandé
CRC32	32 bits	Très rapide	Détection d'erreurs réseau ou stockage, non cryptographique
MD5	128 bits	Rapide	Intégrité non hostile uniquement, à éviter en sécurité
SHA-1	160 bits	Rapide	Obsolète, compatibilité ancienne (Git, vieux paquets)
SHA-256	256 bits	Modérée	Standard actuel, vérification d'intégrité et signatures
SHA-512	512 bits	Rapide en 64 bits	Vérification d'intégrité, marge de sécurité supérieure

MD5 ou SHA-256 pour vérifier mon ISO ?

SHA-256 par défaut. La quasi-totalité des distributions Linux modernes publie SHA-256 et SHA-512, parfois aux côtés de MD5 pour compatibilité historique. Si l'éditeur ne publie que MD5 et que vous craignez une compromission, exigez SHA-256 ou vérifiez la signature GPG du fichier de checksums. Si vous craignez juste une corruption en téléchargement, MD5 suffit techniquement.

Le checksum garantit-il la sécurité de mon fichier ?

Non, pas à lui seul. Un checksum prouve l'intégrité, pas l'authenticité. Si un attaquant contrôle le serveur de téléchargement, il peut publier un fichier modifié et son checksum modifié. La sécurité réelle vient d'une signature numérique (GPG, code signing) qui lie le checksum à une clé privée connue. Récupérez toujours le checksum via HTTPS ou, mieux, via une signature GPG vérifiable.

Mon checksum ne correspond pas, que faire ?

D'abord, vérifiez que vous comparez le bon algorithme : un SHA-256 ne peut pas correspondre à un SHA-1. Ensuite, recommencez le téléchargement, idéalement depuis un autre miroir : la cause la plus fréquente est une coupure réseau. Si l'écart persiste après plusieurs essais, suspectez une compromission du miroir : remontez à la source officielle et vérifiez la signature GPG si elle existe. Ne jamais exécuter ou utiliser le fichier tant que le checksum ne correspond pas.

Pourquoi MD5 est-il déprécié ?

MD5 souffre de collisions pratiques : il est possible de construire deux fichiers différents ayant exactement le même hash MD5 en quelques secondes. Cette propriété viole la fonction même d'un hash cryptographique. Concrètement, un attaquant peut créer un binaire malveillant ayant le même MD5 qu'un binaire légitime. SHA-1 souffre du même problème depuis 2017 (attaque SHAttered). Seuls SHA-256, SHA-512 et leurs variantes restent considérés sûrs en 2026.

Différence entre hash et checksum ?

Un hash est le résultat générique d'une fonction de hachage. Un checksum est un hash utilisé spécifiquement pour vérifier l'intégrité d'une donnée. Tous les checksums sont des hashs, mais tous les hashs ne sont pas des checksums : un hash de mot de passe (bcrypt, argon2) sert à l'authentification, un hash dans une table de hachage sert à indexer rapidement. Le terme fingerprint ou empreinte est un synonyme courant de checksum.

CRC32 suffit-il pour mes besoins ?

CRC32 suffit si vous cherchez uniquement à détecter une corruption accidentelle sur un canal non hostile : transfert réseau interne, vérification d'archive ZIP, contrôle de cohérence en mémoire. Avec seulement 32 bits, deux fichiers aléatoires ont environ 1 chance sur 4 milliards d'avoir le même CRC32 par hasard, ce qui est suffisant pour une détection d'erreur. CRC32 est insuffisant dès qu'un attaquant peut influencer le contenu : il est trivial de forger un fichier avec un CRC32 cible. Pour toute vérification face à un risque malveillant, utilisez SHA-256.

Pourquoi mon checksum diffère-t-il selon l'OS ?

Le checksum d'un même contenu binaire est identique partout. Si vous obtenez deux résultats différents, c'est que le fichier diffère réellement : fins de ligne (CRLF Windows contre LF Unix) après un transfert FTP en mode texte, encodage du texte modifié à l'ouverture, métadonnées ajoutées par le système (résolution Spotlight macOS, attributs étendus), ou recompression silencieuse par un client de transfert. Toujours transférer en mode binaire.

Checksum ou signature numérique ?

Un checksum prouve qu'un fichier n'a pas été altéré entre la publication et la réception, à condition de récupérer le checksum par un canal sûr. Une signature numérique (GPG, PGP, code signing Authenticode) prouve en plus l'identité de l'auteur grâce à une clé privée. La signature englobe et renforce le checksum : la pratique standard chez Debian, Tor, ou Bitcoin Core est de signer en GPG le fichier de checksums, puis d'utiliser ces checksums pour vérifier les binaires.