1. Des fichiers de même nom n'ont pas forcément le même contenu
Lorsque le nom et la taille d'un programme d'installation téléchargé correspondent à la page de téléchargement, on peut penser l'avoir reçu correctement. Pourtant, un nom peut changer et deux fichiers de même taille peuvent contenir des données différentes. Inversement, copier une photo sous un autre nom ne modifie pas nécessairement ses octets. Une fonction de hachage facilite la comparaison : elle soumet le contenu à un calcul défini pour produire une valeur courte, appelée empreinte. La question est de savoir si les octets reçus correspondent à une référence fiable, et pas simplement si le nom paraît plausible. Elle se pose aussi lorsqu'on déplace une sauvegarde sur un autre support.
SHA-256 est un algorithme qui produit une empreinte de 256 bits à partir de son entrée. Celle-ci s'affiche couramment sous forme de 64 chiffres hexadécimaux, car chacun représente quatre bits. La longueur du résultat n'augmente pas proportionnellement à la taille du fichier. Appliquer le même algorithme aux mêmes octets donne le même résultat. Cependant, puisque des valeurs de longueur finie représentent tous les contenus possibles, des collisions, où des entrées différentes produisent la même valeur, existent en principe. Être utile aux comparaisons pratiques ne signifie pas attribuer un nom mathématiquement unique à chaque fichier. Le RFC 6234 fournit des calculs et des données de test, notamment pour SHA-256.
2. Une empreinte n'est ni un chiffrement ni une copie miniature
Connaître une empreinte ne donne pas un bouton de déchiffrement qui restitue le document ou la photo d'origine. Le chiffrement permet de retrouver le texte initial avec une clé appropriée ; une fonction de hachage cryptographique n'est pas un format de stockage permettant cette reconstruction. Cela ne signifie pas que publier seulement une empreinte protège le secret de toute entrée. S'il n'existe que quelques entrées possibles, on peut calculer leurs empreintes et les comparer. Une explication de SHA-256 pour vérifier des fichiers ne doit donc pas devenir un conseil selon lequel hacher directement les mots de passe suffirait à les stocker. Vérification d'intégrité, confidentialité et stockage des mots de passe ont des exigences différentes.
Calculer l'empreinte d'un fichier entier ne revient pas à comparer uniquement les caractères visibles. Des phrases identiques à l'écran peuvent avoir des octets différents selon les fins de ligne, l'encodage ou les métadonnées internes. Un fichier extrait d'une archive est une autre cible de comparaison que l'archive elle-même. Normaliser les caractères ou modifier les fins de ligne avant le calcul produit l'empreinte des données transformées. Si l'éditeur fournit celle de l'archive d'origine, comparez-la d'abord à l'archive téléchargée elle-même. C'est une application concrète de la distinction entre affichage et octets présentée dans l'article précédent sur Unicode et UTF-8.
3. Comparer avec le même algorithme et la bonne référence
Avant de vérifier, contrôlez ensemble la version, le système d'exploitation, le nom du fichier et l'algorithme dans les instructions officielles de l'éditeur. La valeur d'un installateur pour un autre système ou d'une autre version n'est pas la bonne référence. Dans PowerShell, Get-FileHash -LiteralPath '.\download.zip' -Algorithm SHA256 lit un fichier local et calcule son empreinte. Cette commande n'exécute pas le contenu situé à ce chemin. La documentation officielle de Microsoft explique que le calcul porte sur le contenu et qu'un simple changement de nom ne change pas la valeur. Adaptez le nom et le chemin au fichier réellement téléchargé et ne le modifiez pas pendant le calcul.
Dans la sortie, comparez les 64 caractères complets du champ Hash à la valeur SHA-256 publiée. Quelques caractères identiques au début ou à la fin ne prouvent pas une correspondance complète. Les lettres hexadécimales majuscules et minuscules représentent les mêmes nombres ; si d'autres caractères apparaissent ou s'il manque des chiffres, vérifiez d'abord la copie. Une correspondance étaye la cohérence entre les octets reçus et la référence jugée fiable. Elle ne vérifie ni l'exactitude d'un document, ni la qualité d'un programme, ni son comportement malveillant. Si le fichier de référence pose problème, une copie identique a la même empreinte. Réussite du calcul et possibilité d'utiliser le fichier demandent des jugements distincts.
4. Un écart invite à enquêter sans prouver une attaque
Supposons qu'un fichier de distribution reçu hier ne corresponde pas à la valeur des instructions d'aujourd'hui. Il s'agit d'un exemple explicatif, pas du récit d'un incident réel. Vérifiez d'abord si les instructions concernent la même version, si vous avez reçu un fichier pour un autre appareil ou si le calcul a précédé la fin du téléchargement. Vous avez peut-être calculé l'empreinte d'un fichier extrait plutôt que celle de l'archive, ou un éditeur a enregistré le document à nouveau. Il faut distinguer un changement de cible de comparaison d'une modification pendant le transfert ou le stockage. L'écart seul ne dit pas qui a changé quoi ni quand.
N'exécutez pas immédiatement un installateur dont l'empreinte diffère pour l'examiner. Revérifiez les instructions officielles et la référence, puis comparez un nouveau téléchargement. Si l'écart persiste, consultez les corrections ou le support de l'éditeur et conservez le résultat. Notez ensemble l'heure, l'adresse source, la version, l'algorithme et la valeur calculée. Des calculs répétés identiques indiquent une lecture cohérente du fichier local actuel, sans résoudre une référence publiée erronée ni un problème de distribution. Remplacer l'enregistrement de référence par le résultat attendu détruit les éléments nécessaires pour juger les changements ultérieurs.
5. Pourquoi faire confiance à la référence, et à quoi sert la signature ?
Si un attaquant peut modifier à la fois le fichier et l'empreinte annoncée, il peut calculer celle du fichier modifié et la publier comme nouvelle référence. Le NIST SP 800-175B explique cette limite lorsqu'on utilise une empreinte sans clé ni signature. Obtenir la valeur sur une page HTTPS à l'adresse officielle aide à établir la source et le trajet de transmission, mais ne garantit pas que le serveur de distribution lui-même n'a pas été compromis. Ce qui compte est l'origine de la référence et la procédure de confiance qui a permis de l'obtenir, plutôt que la longueur apparente de la chaîne. Deux valeurs copiées sur le même écran qui concordent n'établissent pas à elles seules l'identité du créateur.
Une signature numérique permet de vérifier la relation entre la signature et les données, par exemple avec une clé publique obtenue de manière fiable. Si l'éditeur propose une procédure de vérification, suivez aussi ses instructions officielles pour contrôler le propriétaire et l'empreinte de la clé. Faire simplement confiance à une clé inconnue trouvée à côté d'un fichier d'origine incertaine ne résout pas le point de départ de la confiance. HMAC, qui utilise une clé secrète partagée, est également un outil d'authentification distinct d'une simple empreinte, mais on ne peut pas l'ajouter arbitrairement à chaque téléchargement pour tout résoudre. Une signature valide ne prouve ni l'absence de défauts du programme ni la véracité d'un document. Correspondance des octets, vérification de la source et évaluation du contenu sont liées, mais chacune demande ses propres éléments de preuve.
6. Documenter le périmètre dans les sauvegardes et le travail commun
Pour sauvegarder ses photos, conserver les valeurs SHA-256 des originaux et les comparer aux copies aide à repérer les changements pendant un déplacement. Protégez aussi la liste de référence pour qu'elle ne disparaisse pas ou ne soit pas écrasée avec les originaux. Un logiciel photo peut réécrire l'orientation ou les métadonnées de prise de vue : l'empreinte change alors même si l'image paraît semblable. Distinguez d'abord la conservation exacte des octets de la préservation du sens d'une photo retouchée. Pour vérifier tout un dossier, ne vous arrêtez pas à l'empreinte d'un seul fichier : gérez la liste des fichiers inclus, leurs chemins relatifs et leurs valeurs individuelles.
Dans une relecture collaborative, l'empreinte peut aussi identifier précisément la version examinée. Mais une correspondance d'empreintes ne remplace pas la preuve que quelqu'un a réellement lu tout le texte ou comparé une traduction. Notez ce qui a été relu, quand et comment, puis rattachez cet enregistrement à la valeur du fichier. L'image de cet article est un schéma explicatif original qui organise comparaison des octets, origine de la référence et périmètre de vérification ; ce n'est ni une mesure réelle ni un certificat. Lors d'une vérification, consignez la cible et l'algorithme, l'origine de la référence et les limites de ce que le résultat permet d'affirmer. Une autre personne pourra ainsi reproduire la procédure sans exagérer le sens d'une correspondance ou d'un écart.