> ## Content Index > Fetch the complete content index at: https://www.wikilibriste.fr/llms.txt > Use this file to discover other available public pages before exploring further. # Vérifier l'intégrité d'un fichier - URL: https://www.wikilibriste.fr/verifier-integrite-fichier/ - Published: 2025-04-14T22:00:00.000Z - Updated: 2026-05-19T18:37:44.000Z - Description: Tutoriel pratique pour vérifier l'empreinte et la signature numérique d'un fichier sous GNU/Linux, à jour mai 2026. - Author: ayo - Tags: #tutoriels, #rating-2 Bienvenue dans ce tutoriel. Vous venez de télécharger une ISO, un binaire, une archive, et vous vous demandez si ce fichier est bien celui que son auteur a publié. C'est très simple, vous allez voir ! Nous reprenons ici l'aspect pratique du sujet. Pour la théorie (différence entre empreinte et signature, intérêt de chacune, limites), nous vous renvoyons à notre article de fond [Comprendre l'intégrité des données](https://wikilibriste.fr/integrite-donnees/). Nous allons couvrir deux méthodes complémentaires : - la vérification par **empreinte cryptographique** (hash) pour détecter une altération - la vérification par **signature numérique** (PGP) pour authentifier l'origine du fichier 💡 Une signature PGP valide **implique* l'intégrité (puisqu'elle inclut une empreinte), mais l'****inverse est faux**. Un simple hash ne prouve rien sur l'identité de l'auteur. # Méthode 1 : l'empreinte cryptographique ## Outils nécessaires Sur la plupart des distributions GNU/Linux, les outils de calcul d'empreinte sont déjà installés via le paquet **coreutils** (qui fournit `md5sum`, `sha256sum`, `sha512sum`, `b2sum`...). Si ce n'est pas le cas, ouvrez un terminal et installez-le : | Distribution | Commande | | -------------------------- | ----------------------------- | | Debian, Ubuntu et dérivées | sudo apt install coreutils | | Arch et dérivées | sudo pacman -S coreutils | | Fedora, RHEL et dérivées | sudo dnf install coreutils | | openSUSE | sudo zypper install coreutils | Pour les algorithmes plus modernes (SHA-3, BLAKE3), nous y reviendrons plus bas, c'est un cas particulier. ## Calculer une empreinte Imaginons que vous avez téléchargé une image ISO `monfichier.iso` dans `~/Téléchargements/`, et que l'auteur publie sur son site une empreinte MD5 de valeur `8747e564eb53cb2f1dcb9aae0779c2aa`. 🚨 MD5 et SHA-1 sont ****cassés** depuis longtemps (collisions démontrées). Si vous n'avez que ça, vous pouvez vérifier qu'il n'y a pas eu d'erreur de transfert, mais vous ne devez pas en conclure qu'un attaquant n'a pas substitué le fichier. Préférez SHA-256 ou supérieur dès que c'est possible. Placez-vous dans le dossier où se trouve le fichier puis lancez la commande adaptée à l'algorithme : ```bash cd ~/Téléchargements/ md5sum monfichier.iso ``` Vous obtenez : ``` 8747e564eb53cb2f1dcb9aae0779c2aa monfichier.iso ``` Bravo, vous venez de calculer votre première empreinte. Comparez maintenant ce résultat avec la valeur publiée par l'auteur : - si les deux empreintes sont **identiques**, votre fichier est intact - si elles **diffèrent**, le fichier est altéré (téléchargement interrompu, mirror corrompu, attaque) et vous devez le retélécharger, idéalement depuis un autre mirror ## Vérifier automatiquement avec un fichier .sum Beaucoup de projets publient directement un fichier d'empreinte (par exemple `monfichier.iso.sum` ou `SHA256SUMS`). Ce fichier contient à la fois la valeur du hash et le nom du fichier auquel il se rapporte. Vous pouvez alors laisser `md5sum` faire la comparaison : ```bash md5sum -c monfichier.iso.sum ``` Si tout est bon : ``` monfichier.iso: Réussi ``` Si le fichier est altéré : ``` monfichier.iso: Échec md5sum: Attention : 1 somme de contrôle ne correspond pas ``` 💡 Le fichier `.sum` (ou `SHA256SUMS`) contient déjà le nom du fichier à vérifier. Vous ne le passez ****qu'une seule fois** en argument à `-c`. Pas la peine de répéter le nom de l'ISO derrière. ## Cas SHA-2 (SHA-256, SHA-512) C'est aujourd'hui le standard. Le principe est identique, seule la commande change : ```bash sha256sum monfichier.iso sha512sum monfichier.iso ``` Vous obtenez une suite de 64 caractères hexadécimaux pour SHA-256, 128 pour SHA-512\. Par exemple : ``` 43b796f15f57192dd813306938d199871d9d8b881c0124b43412d81585c0efd5 monfichier.iso ``` La vérification automatique fonctionne pareil : ```bash sha256sum -c SHA256SUMS ``` ## Cas SHA-3 SHA-3 est l'algorithme issu de la compétition Keccak (standardisé en 2015). Il n'a pas de binaire dédié dans `coreutils` (pas de `sha3sum`), il faut passer par OpenSSL : ```bash openssl dgst -sha3-256 monfichier.iso openssl dgst -sha3-512 monfichier.iso ``` 💡 SHA-3 n'a pas remplacé SHA-2\. Les deux familles sont considérées sûres en 2026, et SHA-256 reste le standard de fait pour la distribution de logiciels (Linux, BSD, paquets...). ## Cas BLAKE3 BLAKE3, sorti en 2020, est un algorithme moderne, parallélisable et beaucoup plus rapide que SHA-256 sur les fichiers volumineux. Il n'est pas encore distribué dans `coreutils` (à ne pas confondre avec BLAKE2 qui, lui, fournit `b2sum`). Vous devez encore installer le paquet à part : | Distribution | Commande | | -------------- | ------------------------- | | Debian, Ubuntu | sudo apt install b3sum | | Arch | sudo pacman -S b3sum | | Fedora | sudo dnf install b3sum | | openSUSE | sudo zypper install b3sum | Puis l'usage est calqué sur `sha256sum` : ```bash b3sum monfichier.iso b3sum -c BLAKE3SUMS ``` 💡 BLAKE3 reste minoritaire pour la distribution de logiciels, mais devient courant dans les outils de sauvegarde, de déduplication et certains gestionnaires de paquets. Si un projet vous propose un hash BLAKE3, c'est un bon signe de modernité. # Méthode 2 : la signature numérique Une signature numérique va plus loin que la simple empreinte. Elle prouve à la fois que le fichier n'a pas été altéré **et** qu'il a bien été produit par l'auteur revendiqué (à condition que vous fassiez confiance à sa clé publique). Une protection deux-en-un, pratique non ? Le mécanisme repose sur la **cryptographie asymétrique** combinée à une fonction de hachage. Si vous voulez le détail, l'article de fond [Comprendre l'intégrité des données](https://wikilibriste.fr/integrite-donnees/) couvre toute la mécanique. Le standard le plus répandu pour ce besoin est **OpenPGP**, et son implémentation libre est **GnuPG** (souvent appelée *GPG*). ## Le paysage OpenPGP en 2026 Avant de plonger dans la commande, deux points à connaître pour ne pas être surpris : ⚠️ Depuis juillet 2024, OpenPGP existe en deux variantes incompatibles. La ****RFC 9580** (parfois appelée **crypto-refresh*) modernise le standard original, tandis que ****LibrePGP** est le fork porté par l'équipe GnuPG, qui refuse certains choix de la RFC. En pratique, pour la vérification d'une signature publiée par un projet libre, GnuPG fonctionne dans les deux cas. Pour la création de clés, vous pourriez croiser des incompatibilités entre clients (Sequoia, ProtonMail, GnuPG). 💡 Côté GnuPG : \- La branche ****2.5.19** (avril 2026) est la branche de développement courante, qui deviendra 2.6 stable. \- La branche ****2.4** reçoit ses derniers correctifs jusqu'en juin 2026, après quoi il faudra migrer. Si votre distribution propose encore 2.2 (LTS), elle est officiellement en fin de vie depuis 2024 mais toujours fonctionnelle pour la vérification. ## Installation de GnuPG Si `gpg` n'est pas déjà disponible (vérifiez avec `gpg --version`), installez le paquet correspondant à votre distribution. **Attention, le nom du paquet varie** : | Distribution | Paquet | Commande | | -------------------------- | ------ | ------------------------ | | Debian, Ubuntu et dérivées | gnupg | sudo apt install gnupg | | Arch et dérivées | gnupg | sudo pacman -S gnupg | | Fedora, RHEL et dérivées | gnupg2 | sudo dnf install gnupg2 | | openSUSE | gpg2 | sudo zypper install gpg2 | 💡 Historiquement il existait deux binaires distincts, `gpg` (v1, legacy) et `gpg2` (v2, moderne). Aujourd'hui, **`gpg`** **est l'alias officiel de la v2** sur toutes les distributions à jour. Nous utiliserons `gpg` partout dans ce tutoriel. La commande `gpg2` est encore acceptée comme alias mais sera retirée progressivement. ## Vérifier une signature, cas pratique Nous allons vérifier la signature du fichier d'empreintes d'une image ISO de **Linux Mint 22 (Wilma)**, dont les fichiers sont disponibles sur les mirrors officiels listés sur [linuxmint.com](https://www.linuxmint.com/mirrors.php). Plaçons-nous dans `~/Téléchargements/` après avoir récupéré les trois fichiers utiles : ``` linuxmint-22-cinnamon-64bit.iso sha256sum.txt sha256sum.txt.gpg ``` - l'ISO elle-même - le fichier d'empreintes SHA-256 - la signature PGP du fichier d'empreintes 💡 Linux Mint, comme beaucoup de projets, ne signe pas directement l'ISO. Le projet signe le fichier `sha256sum.txt` qui contient l'empreinte de l'ISO. Si la signature de `sha256sum.txt` est valide ****et** que l'empreinte qu'il contient correspond à votre ISO, vous avez bien la version officielle. Le maillon faible reste votre miroir, ce qui justifie cette double vérification. Si vous ouvrez `sha256sum.txt.gpg` avec un éditeur de texte, vous verrez ceci : ``` -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEJ96xVkTGs88719KRMA+Ea6JbrgkFAmHgoF4ACgkQMA+Ea6Jb rglrYRAApoF9qyaixnA+PmX0pueJSJMRjDXAMmRzvKwUkkqt+CGI2NKiwoYgKDKW [...] -----END PGP SIGNATURE----- ``` Voilà le formalisme d'une signature PGP. Rien de magique, juste un bloc encadré. À noter, l'extension `.asc` désigne en théorie un fichier ASCII et `.gpg` un fichier binaire, mais en pratique l'usage est souvent inversé. Ne vous fiez jamais à l'extension, fiez-vous au contenu. ### Étape 1 : importer la clé publique de l'auteur La clé publique de Linux Mint a pour empreinte : ``` 27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09 ``` Nous la récupérons depuis un serveur de clés public. **Privilégiez HKPS (chiffré, port 443) et non HKP (cleartext, port 80)** : ```bash gpg --keyserver hkps://keyserver.ubuntu.com --recv-key "27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09" ``` 🚨 Un serveur de clés interrogé en HKP cleartext (port 80) expose votre requête à n'importe quel observateur réseau, qui peut deviner ce que vous vous apprêtez à vérifier. Pire, une attaque active peut substituer la clé renvoyée. ****Toujours utiliser** **`hkps://`** **sur le port 443.** GnuPG répond : ``` gpg: clef 300F846BA25BAE09 : clef publique « Linux Mint ISO Signing Key » importée gpg: Quantité totale traitée : 1 gpg: importées : 1 ``` ### Étape 2 : vérifier la signature ```bash gpg --verify sha256sum.txt.gpg sha256sum.txt ``` Si tout est bon : ``` gpg: Signature faite le jeu. 13 janv. 2022 22:57:50 CET gpg: avec la clef RSA 27DEB15644C6B3CF3BD7D291300F846BA25BAE09 gpg: Bonne signature de « Linux Mint ISO Signing Key » [inconnu] gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance. gpg: Rien n'indique que la signature appartient à son propriétaire. Empreinte de clef principale : 27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09 ``` L'expression "**Bonne signature**" est ce qu'il faut retenir. Le fichier d'empreintes a bien été signé par cette clé. À l'inverse, si la signature est invalide : ``` gpg: MAUVAISE signature de « Linux Mint ISO Signing Key » [inconnu] ``` 🚨 Une "MAUVAISE signature" signifie que le fichier a été modifié après signature, ou que vous n'avez pas la bonne clé publique, ou que quelqu'un essaie de vous tromper. Dans tous les cas, ****n'utilisez pas le fichier**. ### Étape 3 : vérifier l'empreinte de l'ISO Maintenant que `sha256sum.txt` est authentifié, vous pouvez l'utiliser pour vérifier l'ISO : ```bash sha256sum -c sha256sum.txt ``` Sortie attendue : ``` linuxmint-22-cinnamon-64bit.iso: Réussi ``` Bravo, votre ISO est intacte et provient bien de Linux Mint. ## Et le message "clef non certifiée" ? Vous avez peut-être remarqué cette ligne : ``` gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance. gpg: Rien n'indique que la signature appartient à son propriétaire. ``` Cela ne veut pas dire que la signature est fausse, juste que **vous n'avez pas encore validé que cette clé appartient bien à Linux Mint**. Pour ça, GnuPG s'appuie sur un *réseau de confiance* (Web of Trust), où les clés sont contre-signées par d'autres. Tant que vous ne signez pas la clé importée avec votre propre clé privée, GnuPG reste prudent. Pour une vérification ponctuelle d'ISO, ce message est normal et acceptable, à condition que vous ayez **récupéré l'empreinte de la clé depuis le site officiel du projet** (et pas seulement depuis le serveur de clés). Un attaquant peut publier une fausse clé sur un keyserver, mais difficilement modifier le site officiel et la documentation. 💡 Pour bien comprendre ces aspects, l'article dédié [Comprendre PGP, OpenPGP et GnuPG](https://wikilibriste.fr/comprendre-pgp/) explique en détail le réseau de confiance et la signature de clés. # Pour aller plus loin Le pendant théorique de ce tutoriel : [Comprendre l'intégrité des donnéesHachage, empreintes et signatures numériques, pour vérifier que vos fichiers n'ont pas été altérés en chemin.Wikilibristeayo](https://www.wikilibriste.fr/integrite-donnees/) L'article compagnon sur la cryptographie qui rend la signature numérique possible : [Comprendre PGP, OpenPGP et GnuPGHistoire, principes cryptographiques, toile de confiance et état des lieux 2026 de PGP, OpenPGP et GnuPG.Wikilibristeayo](https://www.wikilibriste.fr/comprendre-pgp/) Plus technique, pour creuser : - la documentation officielle de GnuPG sur [gnupg.org](https://www.gnupg.org/documentation/) - la FAQ Linux Mint sur la vérification d'ISO, qui détaille le processus complet pour leur projet Voilà, vous savez désormais vérifier qu'un fichier téléchargé est bien celui que vous attendiez. Ce réflexe vous évitera bien des soucis (binaire piégé, ISO altérée par un mirror compromis, paquet substitué). Ce n'est pas non plus une garantie absolue, mais c'est un maillon de plus dans la chaîne de confiance, et ces maillons valent leur poids.