Vérifier l'intégrité d'un fichier avec SHA-256

Le téléchargement corrompu

Vous venez de télécharger une ISO Linux de 2 Go. Vous l'écrivez sur une clé USB, démarrez votre machine, et le programme d'installation échoue avec des erreurs cryptiques une heure plus tard.

Le coupable probable : un seul bit inversé pendant le téléchargement. Un miroir défaillant, une connexion instable ou un proxy qui a tronqué le flux peuvent corrompre un fichier qui semble par ailleurs correct.

C'est exactement à cela que servent les sommes de contrôle. Un hash SHA-256 est une empreinte du fichier : toute modification de l'entrée, même minuscule, produit un hash complètement différent. Vérifiez l'empreinte avant d'utiliser le fichier et le mode de défaillance disparaît.

Qu'est-ce que SHA-256 ?

SHA-256 est une fonction de hachage cryptographique normalisée dans FIPS 180-4. Elle prend n'importe quelle entrée – texte, fichiers, firmware – et produit un résumé hexadécimal fixe de 64 caractères.

Trois propriétés la rendent adaptée au contrôle d'intégrité : elle est déterministe (même entrée, même sortie), à sens unique (impossible de retrouver l'entrée depuis le résumé) et sensible à l'avalanche (changer un bit modifie environ la moitié des bits de sortie).

Un hash correspondant prouve que le fichier est identique octet pour octet à ce que l'éditeur a haché. Il ne prouve pas, en soi, qui l'a haché ni que la somme n'a pas été falsifiée – c'est ce qu'apportent les sommes signées.

Où SHA-256 est utilisé

SHA-256 apparaît partout dans l'informatique moderne :

• Distribution de logiciels – les distributions Linux publient des hash SHA-256 pour toutes les ISO et paquets
• Gestionnaires de paquets – npm, pip et apt vérifient l'intégrité des artefacts
• Contrôle de version Git – les commits et objets sont identifiés par SHA-1 (avec un format d'objet SHA-256 désormais pris en charge)
• SSL/TLS – les certificats sont empreints avec SHA-256
• Systèmes de sauvegarde – déduplication et contrôles d'intégrité
• Blockchain – Bitcoin utilise SHA-256 pour chaîner les blocs

Comment vérifier l'intégrité d'un fichier

1. Obtenez le hash attendu depuis le site officiel, en HTTPS – jamais depuis des forums, miroirs ou résultats de recherche.
2. Générez le hash de votre fichier téléchargé, avec un outil de navigateur ou l'une des commandes ci-dessous.
3. Comparez les deux valeurs caractère par caractère, ou avec le champ de comparaison intégré à l'outil.
4. S'ils correspondent, utilisez le fichier. S'ils ne correspondent pas, supprimez le fichier et téléchargez-le à nouveau depuis un miroir officiel.
5. Pour les téléchargements à forte valeur, vérifiez en plus la signature GPG du fichier de sommes (voir plus bas).

Commandes SHA-256 par plateforme

Voici comment générer des hash SHA-256 sur différentes plateformes :

Get-FileHash filename.iso -Algorithm SHA256
# Or using certutil:
certutil -hashfile filename.iso SHA256

sha256sum filename.iso
# Or on Mac without sha256sum:
shasum -a 256 filename.iso

async function hashFile(file) {
  const buffer = await file.arrayBuffer();
  const hashBuffer = await crypto.subtle.digest('SHA-256', buffer);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

Vérification avec un fichier de sommes

Plutôt que de copier un hash depuis une page web, vous pouvez télécharger le fichier de sommes de la distribution – généralement nommé SHA256SUMS – et vérifier tous vos fichiers en une seule commande.

Le fichier liste des paires hash + nom de fichier. Le mode -c (check) lit ce fichier, hache chaque fichier listé et rapporte OK ou FAILED pour chaque entrée.

C'est à la fois plus rapide et plus sûr que de comparer des hash à l'œil, car la comparaison est exacte et couvre tous les fichiers d'un coup.

# Download the checksums file next to your ISO, then:
sha256sum -c SHA256SUMS
# Expected output for each listed file:
# ubuntu-24.04-desktop-amd64.iso: OK

Sommes signées : défendre la somme elle-même

Une somme de contrôle ne vaut que ce que vaut sa source. Si un attaquant peut remplacer l'ISO sur un miroir, il peut aussi remplacer le fichier SHA256SUMS voisin – une somme provenant d'une source non fiable ne prouve donc rien.

Les grandes distributions signent donc le fichier de sommes avec GPG. Le flux : importez la clé de signature officielle de la distribution (en HTTPS), vérifiez la signature de SHA256SUMS, et seulement ensuite faites confiance aux hash qu'il contient.

Cela transforme un point de défaillance unique en deux étapes vérifiables : la signature prouve que les sommes proviennent de l'éditeur, et les sommes prouvent que les fichiers proviennent de l'éditeur.

# Example with Ubuntu-style releases (adjust filenames per distribution)
gpg --verify SHA256SUMS.gpg SHA256SUMS
sha256sum -c SHA256SUMS

Automatiser la vérification des sommes

Pour les équipes et les utilisateurs avancés, la vérification doit être dans le pipeline, pas dans la mémoire :

Les jobs CI doivent vérifier les artefacts téléchargés contre une somme épinglée avant de compiler ou tester

Les scripts doivent échouer immédiatement en cas de discordance – une nouvelle tentative silencieuse peut masquer un problème de chaîne d'approvisionnement

Gardez les hash attendus dans un manifeste signé et versionné, pas dans un README

Vérifiez les images avant de les écrire sur une clé USB ou une carte SD, pas après un démarrage en échec

SHA-256 face aux autres algorithmes

Utilisez SHA-256 pour tout nouveau travail d'intégrité. Il est sûr, universellement pris en charge et recommandé par les orientations de transition du NIST.

SHA-1 est cassé pour la résistance aux collisions – des chercheurs ont démontré de vraies collisions. Ne vous fiez pas à SHA-1 pour la sécurité.

MD5 est totalement cassé pour la sécurité. Il convient comme somme rapide non sécurisée pour la déduplication, mais jamais pour l'intégrité face à un attaquant motivé.

SHA-512 offre un résumé plus long et est plus rapide sur les CPU 64 bits, mais SHA-256 est la norme de l'écosystème – les éditeurs le publient et les outils l'attendent.

Ce que les hash ne peuvent pas faire

Un hash prouve qu'un fichier n'a pas changé depuis son hachage. Il ne prouve pas qui l'a créé, quand, ni que la source du hash était légitime.

Prouver la paternité exige des signatures numériques – de la cryptographie à clé publique sur le hash, comme dans le flux des sommes signées ci-dessus.

Et les hash ne fournissent pas la confidentialité. Hacher un mot de passe produit une valeur déterministe que les attaquants peuvent forcer ; les mots de passe exigent des KDF lents et salés comme Argon2id, scrypt ou bcrypt, jamais du SHA-256 brut.

Questions fréquentes

Références

Cet article s'appuie sur les normes industrielles et les bonnes pratiques de sources autoritatives :

• NIST FIPS 180-4 – Secure Hash Standard (SHS) : https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• NIST SP 800-131A Rev.2 – Transition de l'utilisation des algorithmes cryptographiques et longueurs de clé : https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
• RFC 6234 – US Secure Hash Algorithms (SHA et HMAC/HKDF basés sur SHA) : https://www.rfc-editor.org/rfc/rfc6234
• Aide-mémoire OWASP sur le stockage cryptographique : https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html