> ## 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.

# Comprendre l'intégrité des données
- URL: https://www.wikilibriste.fr/integrite-donnees/
- Published: 2026-05-23T06:00:00.000Z
- Updated: 2026-06-22T14:12:08.000Z
- Description: Hachage, empreintes et signatures numériques, pour vérifier que vos fichiers n'ont pas été altérés en chemin.
- Author: ayo
- Tags: Identité & Authentification, #articles, #rating-2

Le triptyque CIA

Étape 2 sur 3

1. 01 [Comprendre le chiffrement](https://www.wikilibriste.fr/chiffrement/)
2. 02 Comprendre l'intégrité
3. 03 [La disponibilité des données](https://www.wikilibriste.fr/sauvegarder-donnees/)

💡

Cet article est le deuxième volet d'une série consacrée au triptyque ****CIA** de la sécurité de l'information : ****C**onfidentialité, ****I**ntégrité, ****D**isponibilité (oui, le "D" devient "A" en anglais pour **Availability*, et ça donne "CIA", ce qui est plus marquant). Nous avons déjà couvert la confidentialité dans notre [article sur le chiffrement](https://wikilibriste.fr/chiffrement).  
  
Ici, nous nous attaquons à l'****intégrité**. La disponibilité est traitée dans notre [article sur la sauvegarde de vos données](https://wikilibriste.fr/sauvegarder-donnees/). Et un article dédié à PGP/GPG complétera la série pour creuser la signature numérique en profondeur.

---

Si vous êtes ici, c'est probablement parce que vous avez déjà téléchargé une image ISO de Linux, un installateur de logiciel ou un fichier important, et que quelqu'un vous a parlé de "vérifier l'empreinte" sans que cela soit très clair.

Vous êtes au bon endroit, nous allons démystifier tout cela ensemble.

## Mais l'intégrité, c'est quoi exactement ?

Reprenons la définition la plus simple :

> **L'intégrité d'une donnée, c'est l'état fiable et crédible de cette donnée. (Larousse)**

La norme [ISO/IEC 27000](https://www.iso.org/standard/73906.html) (référence des normes de sécurité de l'information) la définit comme *"la propriété d'exactitude et de complétude"*. Autrement dit : la donnée que vous lisez est-elle exactement celle qui a été produite à l'origine, sans altération volontaire ni accidentelle ?

Dans le monde numérique, une donnée a un **cycle de vie**. Elle est créée, copiée, transférée, stockée, parfois pendant des années. À chaque étape, elle peut être altérée :

- de façon **involontaire** : un bit qui bascule lors d'un transfert, une corruption disque, un bug logiciel
- de façon **volontaire** : un attaquant qui injecte un malware dans un installateur ou modifie un fichier en transit

Vérifier l'intégrité, c'est s'assurer qu'aucune de ces deux choses n'est arrivée.

## Intégrité, confidentialité, authenticité : ne pas confondre

Beaucoup de gens utilisent ces trois mots de façon interchangeable. Ils désignent pourtant des propriétés différentes, qui se complètent :

| Propriété           | Question à laquelle elle répond                                      | Outil typique                         |
| ------------------- | -------------------------------------------------------------------- | ------------------------------------- |
| **Confidentialité** | Personne d'autre que le destinataire ne peut lire la donnée ?        | Chiffrement (AES, ChaCha20)           |
| **Intégrité**       | La donnée n'a-t-elle pas été modifiée entre émission et réception ?  | Fonction de hachage (SHA-256, BLAKE3) |
| **Authenticité**    | Cette donnée vient-elle bien du destinataire qui prétend l'envoyer ? | Signature numérique (Ed25519, RSA)    |

💡

Une donnée peut très bien être chiffrée (confidentielle) et altérée (intégrité compromise) en même temps.  
  
****Les 3 propriétés se construisent par couches**.

## Pourquoi vérifier absolument un fichier téléchargé ?

Un fichier qui transite par internet peut subir toutes sortes de mésaventures. Voici les cas concrets que nous rencontrons régulièrement.

### Le dépôt compromis

Un attaquant pénètre le serveur de téléchargement d'un éditeur et remplace l'installateur officiel par une version compromise (avec trojan par exemple). Et non, ce n'est pas de la science-fiction :

- En 2017, [le logiciel CCleaner a été infecté à la source](https://www.latribune.fr/technos-medias/informatique/le-logiciel-ccleaner-infecte-par-un-malware-2-3-millions-d-utilisateurs-touches-750834.html), touchant **2,3 millions** d'utilisateurs.
- En 2024, [la backdoor XZ Utils](https://en.wikipedia.org/wiki/XZ%5FUtils%5Fbackdoor) (CVE-2024-3094) a frôlé la catastrophe : un mainteneur malveillant a injecté du code dans une bibliothèque de compression utilisée par quasiment toutes les distributions Linux.
- En 2025-2026, les attaques sur la chaîne d'approvisionnement logicielle ont été pointées par l'ANSSI comme une tendance majeure. Très [récemment](https://www.theregister.com/cyber-crime/2026/05/12/cache-poisoning-caper-turns-tanstack-npm-packages-toxic/5238650) encore sur NPM !

### L'attaque de l'homme du milieu (MITM)

Un attaquant placé entre vous et le serveur de téléchargement intercepte la connexion et substitue le fichier à la volée. HTTPS limite ce risque, mais il ne le supprime pas (DNS empoisonné, faux certificat, Wi-Fi public hostile).

### Et puis, la corruption toute simple

Ici, nul besoin d'attaquant : un disque qui vieillit, un transfert interrompu, une mauvaise copie. Le fichier que vous avez téléchargé n'est tout simplement pas complet ou est "corrompu".

🚨

****Conséquence concrète** : si vous installez un système d'exploitation à partir d'une ISO altérée, vous pouvez compromettre la machine cible et toutes vos données. Vérifier l'empreinte avant l'installation prend 30 secondes ; reformater une machine compromise prend des heures et restaurer des données perdues prend parfois toute une vie !

## L'empreinte numérique, votre détecteur de modification

Pour vérifier qu'un fichier n'a pas bougé, on lui calcule une **empreinte** (en anglais *checksum*, *hash* ou *digest*). C'est une chaîne courte de caractères calculée à partir du contenu du fichier par un algorithme appelé **fonction de hachage**.

Pour bien comprendre, voici une analogie : imaginez le sceau de cire rouge que l'on apposait autrefois sur les lettres. Si le sceau est intact à l'arrivée, le destinataire sait que personne n'a ouvert l'enveloppe en chemin. L'empreinte numérique joue exactement ce rôle, en bien plus précis et plus actuel.

### Trois propriétés clés

Une bonne fonction de hachage cryptographique garantit que :

- **Le résultat est déterministe** : le même fichier donne toujours la même empreinte sur n'importe quel ordinateur.
- **Le calcul est à sens unique** : impossible (en pratique) de reconstruire le fichier à partir de l'empreinte.
- **Les collisions sont improbables** : 2 fichiers différents ne produisent quasiment jamais la même empreinte. Le mot "quasiment" est important, nous y revenons juste après **\***. Concrètement, si vous changez un seul octet dans un fichier de 4 Go, l'empreinte produite sera complètement différente. C'est ce qu'on appelle l'**effet d'avalanche**.

#### \* Pourquoi "Quasiment" et non "Jamais" ?

Une fonction de hachage prend une entrée de taille arbitraire (un fichier de 1 Ko ou de 10 Go peu importe) et la compresse en une empreinte de taille fixe (par exemple : 256 bits pour [**SHA-256*](https://csrc.nist.gov/pubs/fips/180-4/upd1/final), soit environ 1,16 x 10⁷⁷ valeurs possibles).  
  
Comme il existe une infinité de fichiers possibles mais un nombre fini d'empreintes, ****il existe forcément des couples de fichiers différents qui partagent la même empreinte** (**principe des tiroirs*).

Ce qu'une fonction de hachage cryptographique garantit, ce n'est donc pas l'absence de collisions, c'est qu'****il est mathématiquement infaisable d'en trouver une**. Pour SHA-256, trouver une collision par force brute demande en moyenne 2¹²⁸ opérations (environ 3,4 x 10³⁸), ce qui reste hors de portée de toute l'informatique mondiale réunie pour les décennies à venir.

C'est exactement pour cette raison que ****MD5 et** [****SHA-1**](https://datatracker.ietf.org/doc/html/rfc3174) **sont déconseillés** : ce n'est pas qu'on a "découvert" qu'ils avaient des collisions (toute fonction de hachage en a, par construction), c'est qu'on sait désormais en **produire à volonté* en quelques heures sur du matériel grand public (enfin, surtout MD5). La fonction ne joue donc plus son rôle de garantie d'intégrité. SHA-256, [SHA-3](https://csrc.nist.gov/pubs/fips/202/final) ou BLAKE3 restent eux solides : on sait que des collisions existent quelque part dans l'univers mathématique, mais personne n'a les moyens d'en exhiber une (pour le moment).

D'où la terminologie employée ici "quasiment" : parce que le "jamais" est mathématiquement faux.  
  
Cette partie est bien entendu pour les plus puristes d'entre nous !

#### Hachage simple vs hachage cryptographique

Petite précision (souvent oubliée) : il existe deux familles de fonctions qui produisent des empreintes.

- Les fonctions à ****code de redondance cyclique** (CRC32, CRC64) : conçues pour détecter les erreurs **accidentelles* de transmission. Rapides mais cassables volontairement. C'est ce que votre carte réseau utilise en interne.
- Les fonctions de ****hachage cryptographique** (SHA-2, SHA-3, BLAKE) : conçues pour résister à un attaquant qui chercherait activement à produire une collision. C'est ce qui nous intéresse ici.

Quand un fournisseur publie une empreinte de fichier, il utilise (normalement) une fonction de hachage cryptographique.

## Quel algorithme choisir en 2026 ?

En cryptographie, les algorithmes vieillissent : ce qui était sûr il y a 10 ans peut l'être beaucoup moins, voire être cassé aujourd'hui.

Voici l'état des lieux à l'heure où nous écrivons ces lignes :

| Algorithme                     | Statut 2026          | Quand l'utiliser                                                                      |
| ------------------------------ | -------------------- | ------------------------------------------------------------------------------------- |
| **SHA-3** (SHA3-256, SHA3-512) | ✅ Recommandé         | Choix sûr, indépendant structurellement de SHA-2                                      |
| **SHA-2** (SHA-256, SHA-512)   | ✅ Recommandé         | Le plus répandu, par défaut dans la majorité des outils                               |
| **BLAKE3**                     | ✅ Sûr et très rapide | Performances maximales (4 à 10 fois plus rapide que SHA-256), usage non-réglementaire |
| **BLAKE2**                     | 🟡 Acceptable        | Sera progressivement remplacé par BLAKE3                                              |
| **SHA-1**                      | 🛑 À proscrire       | Cassé depuis 2017 (collision *SHAttered* publiée par Google)                          |
| **MD5**                        | 🛑 À proscrire       | Cassé depuis 2004, encore (trop) répandu                                              |
| **MD6, autres**                | 🛑 À proscrire       | Rarement utilisés, parfois cassés, jamais recommandés                                 |

⚠️

Si un site vous propose ****uniquement** une empreinte MD5 ou SHA-1 à vérifier, méfiez-vous : même si l'empreinte que vous calculez correspond, cela ne prouve plus rien. Un attaquant capable de modifier le fichier peut aussi forger une empreinte MD5 identique. Cherchez un miroir qui propose du SHA-256 ou demandez à l'éditeur.

### Et l'ère post-quantique ?

Vous entendrez sûrement parler de "menace quantique" et de "cryptographie post-quantique".

**Bonne nouvelle** : les fonctions de hachage comme SHA-2 et SHA-3 résistent aux ordinateurs quantiques (l'algorithme de Grover divise la sécurité par deux mais SHA-256 reste largement assez robuste).

Ce sont les **signatures numériques** (RSA, ECDSA) qui sont les plus exposées, et c'est pour cela que le NIST a finalisé en 2024 ses premiers standards post-quantiques (ML-DSA, SLH-DSA).

Nous y reviendrons dans le futur article PGP.

## Vérifier une empreinte en pratique

Sur la plupart des distributions GNU/Linux (Debian, Ubuntu, Fedora, Arch, openSUSE...), les outils de calcul d'empreintes sont **déjà installés** via le paquet `coreutils`. Vous disposez nativement de :

- `md5sum` (à éviter, mais utile pour vérifier de vieux fichiers)
- `sha1sum` (à éviter aussi)
- `sha256sum`, `sha384sum`, `sha512sum` (la famille SHA-2)
- `b2sum` (BLAKE2)

Pour **SHA-3**, il n'existe pas encore (2026) de commande standalone dans coreutils. En attendant l'arrivée de `cksum --algorithm sha3` dans une version stable, utilisez OpenSSL :

```
openssl dgst -sha3-256 mon-fichier.iso

```

Pour **BLAKE3**, le paquet `b3sum` est séparé : `pacman -S b3sum` sur Arch, `dnf install b3sum` sur Fedora, ou `cargo install b3sum` sur les autres distributions.

Le principe est toujours le même :

```
sha256sum mon-fichier.iso

```

Vous obtenez une chaîne de 64 caractères hexadécimaux que vous comparez à celle publiée par le fournisseur. Si elles sont identiques, le fichier est intègre.

💡

Pour la procédure pas à pas avec exemples, captures et cas SHA / GPG, rendez-vous dans notre tutoriel dédié à la vérification d'intégrité :

[Vérifier l’intégrité d’un fichierComment vérifier qu’un fichier téléchargé est authentique et non altéré, avec les méthodes empreinte (hash) et signature numérique (GPG).![](https://www.wikilibriste.fr/content/images/icon/Logo---exp-1-177.svg)Wikilibristeayo![](https://www.wikilibriste.fr/content/images/thumbnail/verif-integrite-6.png)](https://www.wikilibriste.fr/verifier-integrite-fichier/)

## Aller plus loin : la signature numérique

L'empreinte seule a une limite : elle prouve que le fichier n'a pas changé **entre** son téléchargement et votre vérification, mais elle ne prouve pas **qui** l'a publié.

Si un attaquant compromet le site officiel d'un éditeur, il peut très bien remplacer le fichier **et** son empreinte affichée. Vous calculerez la même empreinte que celle publiée et tout semblera bon. Vous voyez le problème ?

C'est là qu'intervient la **signature numérique**.

![](https://www.wikilibriste.fr/content/images/2026/05/signature_pgp.png)

Principes de base d'une signature numérique (Source : CNIL.fr)

L'idée :

- L'éditeur calcule l'empreinte du fichier (via SHA-2 ou BLAKE3)
- Il la chiffre avec sa **clé privée** (que lui seul possède)
- Il publie le résultat (la *signature*) à côté du fichier
- Vous vérifiez la signature avec sa **clé publique** (récupérée de façon fiable au préalable)

Si tout concorde, vous savez deux choses : le fichier n'a pas bougé (intégrité) **ET** il a bien été signé par celui qui détient la clé privée correspondante (authenticité). Deux propriétés CIA d'un coup, plutôt élégant.

L'outil le plus utilisé dans le monde libre pour signer des fichiers, des courriels et des paquets logiciels est **GnuPG** (souvent appelé *GPG*), une implémentation libre du protocole **OpenPGP**.

⚠️

****À savoir** : depuis 2024, l'écosystème OpenPGP est traversé par un schisme. L'IETF a publié la nouvelle norme [RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html) (juillet 2024) qui modernise le format avec OpenPGP v6\. GnuPG 2.5 (branche stable en 2026) suit en parallèle une spécification dérivée appelée **LibrePGP*, ce qui crée des soucis d'interopérabilité. Les distributions Linux appliquent généralement les patches du projet **FreePG* pour rester compatibles RFC 9580\. Pour la vérification de signatures simples (le cas le plus courant), tout fonctionne encore. Nous traiterons cela en détail dans l'article PGP dédié.

### Cryptographie asymétrique : une vue d'ensemble

Sans entrer dans les détails (qui mériteraient leur propre article), la signature numérique repose sur la **cryptographie asymétrique** : 

> 2 clés mathématiquement liées, où ce que l'une fait, l'autre seule peut le défaire.

- On **signe** avec sa clé **privée**, on **vérifie** avec la clé **publique**.
- On **chiffre** avec la clé **publique** du destinataire, il **déchiffre** avec sa clé **privée**.

🚨

****Une règle absolue** : une clé privée ne se transmet ****jamais**, sous aucun prétexte, et surtout pas par réseau. Elle reste sur votre machine, idéalement protégée par une phrase de passe robuste.

Pour la pratique (importer une clé publique, vérifier une signature, gérer son trousseau), notre tutoriel de vérification d'intégrité couvre la procédure pas à pas avec un cas réel.

## Pour aller plus loin

- Vérifier l'intégrité d'un fichier (tutoriel) : la procédure pas à pas

[Vérifier l’intégrité d’un fichierComment vérifier qu’un fichier téléchargé est authentique et non altéré, avec les méthodes empreinte (hash) et signature numérique (GPG).![](https://www.wikilibriste.fr/content/images/icon/Logo---exp-1-176.svg)Wikilibristeayo![](https://www.wikilibriste.fr/content/images/thumbnail/verif-integrite-5.png)](https://www.wikilibriste.fr/verifier-integrite-fichier/)

- Comprendre le chiffrement : le pendant "confidentialité" de cet article

[Le ChiffrementArticle traitant des notions de chiffrement dans son ensemble et les outils recommandés.![](https://www.wikilibriste.fr/content/images/icon/Logo---exp-1-175.svg)Wikilibristeayo![](https://www.wikilibriste.fr/content/images/thumbnail/photo-1724304406928-c43b01912fa1-9)](https://www.wikilibriste.fr/chiffrement/)

- Sauvegarder ses données : le pendant "disponibilité" de cet article

[Sauvegarder ses donnéesSauvegarder pour ne rien perdre, restaurer pour repartir vite. Voici notre méthode complète sous Linux et Android.![](https://www.wikilibriste.fr/content/images/icon/Logo---exp-1-202.svg)Wikilibristemarmotte![](https://www.wikilibriste.fr/content/images/thumbnail/photo-1597852074816-d933c7d2b988-1)](https://www.wikilibriste.fr/sauvegarder-donnees/)

Plus technique, pour les initiés :

- [RFC 9580 : OpenPGP](https://www.rfc-editor.org/rfc/rfc9580.html) : la norme de référence (en anglais, technique)
- [Annexe B1 du RGS de l'ANSSI](https://cyber.gouv.fr/publications/mecanismes-cryptographiques) : les algorithmes recommandés en France

---

*Contributeur(s) : Ayo, marmotte, Theudric*