La vérification de la somme de contrôle (ou empreinte) permet de savoir si le fichier téléchargé est bien le même que celui normalement proposé par un tiers. Nous vous proposons plusieurs moyens de mener à bien cette opération sur Windows, macOS et Linux.
La pratique n’est guère répandue et est pourtant bien utile. Il existe plusieurs raisons pouvant pousser à vérifier qu’un fichier est bien ce qu’il prétend être. La principale est la sécurité : on veut s’assurer qu’un fichier téléchargé est celui que l’éditeur concerné pense proposer. C’est d’autant plus utile qu’il est déjà arrivé que des sites officiels soient piratés et que les fichiers proposés soient infectés par des malwares.
Les contrôles d’intégrité permettent donc de s’assurer que le téléchargement est bien identique à ce que les développeurs avaient l’intention de proposer, puisque les sommes de contrôle sont – normalement – calculées avant mise à disposition sur les serveurs. Attention, dans le cas d’un piratage, il est possible que l’information affichée sur le site ait été elle-même modifiée. Ce sont cependant des cas rares.
L’autre grande raison à cette vérification d’intégrité est qu’un téléchargement peut mal se passer. Les données peuvent être corrompues, ce qui peut être particulièrement problématique dans le cas d’une image ISO qui servira à installer un système d’exploitation. Dans nos exemples, nous nous servons justement de l’image ISO d’Ubuntu 22.04.2 (la dernière révision LTS).
Windows : en passant par la ligne de commande
Nous nous concentrons sur Windows 10 et 11, les seules versions supportées actuellement par Microsoft. On peut se servir de PowerShell pour lancer cette vérification, par exemple depuis le Terminal, intégré dans Windows 11 et installable sur Windows 10 depuis le Microsoft Store (gratuit).
Dans le cas de notre image ISO, le « checksum » est celui-ci :
b98dac940a82b110e6265ca78d1320f1f7103861e922aa1a54e4202686e9bbd3
La commande qui nous intéresse dans PowerShell se nomme « Get-FileHash ». Commencez par ouvrir une session PowerShell ou Terminal (par exemple en ouvrant le menu Démarrer puis en écrivant les premières lettres de ce que vous souhaitez lancer), puis entrez la commande suivante, sans valider :
Get-FileHash
Appuyez sur espace, puis faites glisser le fichier qui vous intéresse dans la fenêtre du Terminal. Le chemin d’accès va s’écrire de lui-même, ce qui vous permettra de valider. Le résultat donné sera forcément pour la fonction de hachage SHA256, les anciennes fonctions MD5 et SHA-1 étant obsolètes.
Vous obtiendrez alors un résultat comme celui-ci, qui correspond à l’information fournie par l’entreprise :
Conséquence, l’image ISO est bien ce qu’elle prétend être. Attention, l’opération peut durer plus ou moins longtemps en fonction de la taille du fichier et surtout des performances de votre ordinateur.
Windows : en passant par un utilitaire
Il existe de nombreuses manières d’obtenir l’empreinte d’un fichier sous Windows. Nous allons parler ici d’OpenHashTab, une extension pour le shell de Windows et s’intégrant dans la fenêtre Propriétés d’un fichier ou d’un dossier.
Rien à écrire ici, il suffira de faire un clic droit sur un élément et d’aller chercher la ligne « Propriétés ». Les informations qui nous intéressent se trouvent dans l’onglet Sommes :
Après calcul des sommes (attendre que la barre verte soit remplie), la zone blanche affiche les informations pour MD5, SHA-1, SHA256 et SHA512. Un double-clic permet de copier l’information dans le presse-papier. On peut également coller dans le champ « Comparer à » l’empreinte fournie par Canonical, la fenêtre affichant alors ce dont il s’agit. Ici, on voit bien que le résultat correspond.
macOS : en passant par la ligne de commande
Là encore, une commande en ligne existe et on peut la lancer depuis le Terminal. Le maniement est globalement le même que dans le cas précédent, via la commande ci-dessous :
shasum -a 256
Après avoir ajouté une espace, on fait glisser le fichier dans la fenêtre depuis le Finder, afin que le chemin d’accès s’inscrive tout seul. Après quoi on valide. Une fois que le calcul est terminé, on obtient le résultat suivant :
Il s’agit bien de l’empreinte SHA256 fournie par Canonical, ce qui valide l’intégrité du fichier.
Linux : en passant par la ligne de commande
Linux possède aussi sa fonction en ligne de commande pour vérifier l’empreinte SHA256 d’un fichier. Elle se nomme sha256sum et s’utilise de la même manière que ce que l’on a déjà vu.
sha256sum
Pas besoin ici de paramètres ou autres, il suffit de laisser une espace après la commande et de faire glisser le fichier, toujours pour compléter le chemin d’accès.
Encore une fois, on peut voir que la somme de contrôle fournie correspond à celle attendue.
Autres exemples d’applications
Les moyens de vérifier une empreinte ne manquent pas, quelle que soit la plateforme. Il existe même des applications mobiles pour le faire, sur Android comme sur iOS, mais nous ne traitons ici que le cas des personnes sur ordinateurs, beaucoup plus à même de faire face à ce genre de besoin.
Voici donc quelques exemples d’autres petites applications, à commencer par QuickHash, que l’on peut utiliser sur les trois plateformes majeures (dans le cas de macOS, uniquement sur les Mac Intel malheureusement). Elle a exactement la même interface sur les trois systèmes et se présente ainsi :
Il suffit de faire glisser un fichier dans la fenêtre pour que le calcul commence. On sélectionne ensuite à gauche la fonction qui nous intéresse pour en afficher les informations. On peut également coller l’empreinte fournie par l’éditeur dans le champ « Expected Hash Value », l’application affichant alors un message pour avertir du succès ou de l’échec de la comparaison.
Sur macOS, Hash/Check est une petite application universelle, gratuite, disponible sur l'App Store et particulièrement légère. L’interface est réduite à sa plus simple expression, avec un fichier à faire glisser et des empreintes SHA256, 384 et 512 s’affichant ensuite. Ici aussi, un champ permet de coller l’empreinte obtenue chez l’éditeur, l’application affichant la correspondance en vert si les empreintes sont identiques, ou en rouge si elles ne correspondent pas.
Sur Linux, GtkHash fournit le même genre de service. On peut cliquer dans le champ Fichier ou y faire glisser l’élément à contrôler. Comme précédemment, on peut coller l’empreinte obtenue à la source dans le champ « Vérifier ». Après calcul de la somme via le bouton « Hachage » en bas à droite, l’application indiquera par des pastilles vertes si les informations correspondent.
Commentaires (36)
#1
Sous KDE, faire clic-droit, propriétés, sommes de contrôle, et voilà :)
#2
j’utilise FreeCommander comme explorateur de fichier, c’est aussi intégré :)
#3
N-ième article de vulgarisation qui a perdu sa cible. Rien que le titre (s’il était lu par toute la population) n’attirerait qu’une infime partie. Il serait temps d’intégrer à tous téléchargement un certificat, que la famille Michu serait à mène de comprendre .
#3.1
Mme Michu ne sait déjà pas faire la différence entre stockage et mémoire, alors un certificat…
#3.2
C’est exactement pour ça qu’il faut lui expliquer.
#3.3
je ne pense pas que nxi (ou n’importe quelle organe de presse spécialisée) soit destiné aux mme michu…
#4
C’est qui la cible ?
#4.1
Tout français moyen, qualifié de sans dents ou ceux qui ne sont rien …
#4.2
Dans le monde professionnel, y’a pas mal de monde à toucher. Ça me fait penser à mon fournisseur d’automates industriels : logiciel de plus de 1Go, serveur lent, téléchargement échoue systématiquement, pas de FTP proposé, pas de hash proposé.
Ils voient pas l’intérêt, tu peux juste installer un logiciel automate vérolé ou mal téléchargé et planter ton installation industrielle. Mais je ne vous conseille pas ces automates.
#5
Moi j’attends la généralisation de BLAKE-3 : https://github.com/BLAKE3-team/BLAKE3. C’est juste infernalement plus rapide que sha256. Et aussi sécurisé (normalement…)
#5.1
Très Intéressant. Merci Glandos.
Mais en pratique, un Hash sur une machine moderne, n’est-il pas limité par la vitesse de lecture des données sur disque ou SSD plutôt que l’algo lui même sur CPU ou GPU ? (C’est une vrai question).
J’avais cru comprendre qu’un Hash, c’était en gros des sommes de bits particulières calculées modulo un très grand nombre premier. La somme pouvait se faire en temps réel au cours de lecture séquentielle des données, restait quelques divisions, qui si grand soit le nombre à diviser, ne nécessitent que “quelques” cycles d’horloges, soit bien moins que le temps de lire un gros fichiers à hasher (sauf pour un très petit fichier).
J’avais du mal comprendre apparemment. Tu saurais m’expliquer ?
#5.2
/tmp ❯ ls -lh conduit-c9493ff3f3a683aa
-rwxr-xr-x 1 user user 528M 7 août 2022 conduit-c9493ff3f3a683aa*
/tmp ❯ hyperfine “b3sum conduit-c9493ff3f3a683aa” “sha256sum conduit-c9493ff3f3a683aa” “b3sum –num-threads 1 conduit-c9493ff3f3a683aa”
Benchmark 1: b3sum conduit-c9493ff3f3a683aa
Time (mean ± σ): 31.4 ms ± 0.9 ms [User: 296.2 ms, System: 36.9 ms]
Range (min … max): 29.8 ms … 34.1 ms 86 runs
Benchmark 2: sha256sum conduit-c9493ff3f3a683aa
Time (mean ± σ): 1.734 s ± 0.002 s [User: 1.666 s, System: 0.068 s]
Range (min … max): 1.730 s … 1.739 s 10 runs
Benchmark 3: b3sum –num-threads 1 conduit-c9493ff3f3a683aa
Time (mean ± σ): 167.0 ms ± 1.0 ms [User: 145.4 ms, System: 21.4 ms]
Range (min … max): 165.2 ms … 168.6 ms 17 runs
Summary
‘b3sum conduit-c9493ff3f3a683aa’ ran
55.23 ± 1.54 times faster than ‘sha256sum conduit-c9493ff3f3a683aa’
Donc, j’ai un fichier de 530 Mo, sur un système de fichiers de type tmpfs, c’est à dire en RAM. J’ai un Ryzen 4750G Pro, avec 8 cœurs hyperthreadés. La vitesse de lecture importe peu, et hyperfine lance autant de fois la commande que nécessaire pour avoir un résultat significatif. Dans ce cas, on voit que BLAKE3 et son parallélisme défonce complètement sha256. Par un facteur 55. Et même quand je force b3sum à n’utiliser qu’un seul thread, ça fait ×5 sur la vitesse d’exécution.
Pour le détail d’algorithmie, euuuuh, je passe mon tour pour ce soir :)
#5.3
Je pense que tu confonds le hachage tel qu’utilisé dans les tables de hachage, qui se fait à très grande vitesse et avec seulement quelques opérations, et le hachage de qualité cryptographique (i.e. pour lequel il est quasi-impossible de trouver des collisions), et qui lui peut être très lent puisque les algos utilisés sont beaucoup plus complexes.
#5.4
La vitesse des algorithmes de hash était limité par l’IO (la vitesse du disque). Avec les disque NVME ce n’est plus vraiment le cas.
Les tests de Glandos le montre très bien : Si on prend le plus lent (qui est sha256sum) on a une durée moyenne de 1.734s pour calculer le hash d’un fichier de 528Mo, ce qui fait un débit de ~300 Mo/s
Par contre je ne retrouve pas ces performances avec un vieux CPU i7-5820K, voici mon protocole de test (assez basique) :
dd if=/dev/urandom of=/tmp/big.bin bs=1M count=512
time sha256sum /tmp/big.bin
J’obtiens une durée de 1.2s, soit un débit de 426 Mo/s
#5.5
Car ton CPU n’a pas les instructions hardwares pour le SHA.
De mémoire, BLAKE3 est plus rapide car sa structure cryptographique est compatible avec l’approche SIMD. Mais ce n’est pas du parallélisme au sens coeurs de calculs, c’est du parallélisme au sens instructions.
Pas forcément vrai. Quand je compare 2 hashs visuellements, je regarde les 3 premiers et derniers valeurs hex du condensat. Si ça diffère c’est que les deux fichiers sont différents, sinon je continue de par paquet de 3. Les hash cryptographiques sont conçu pour qu’un bit de différence entraîne un décalage significatif dans le hash.
Petite précaution, CRC32 n’est pas un hash cryptographique. Il est beaucoup plus propice aux collisions.
#5.6
Ce n’est pas logique comme explication, car je suis bien plus rapide (426 Mo/s vs 300Mo/s) ! Je n’explique pas la lenteur du test réalisé par Glandos. J’ai testé avec un PC bien plus récent i7 gen 10, et j’obtiens les mêmes performances (420 Mo/s)
#5.7
Moi je répondais à un message qui disait “J’avais cru comprendre qu’un Hash, c’était en gros des sommes de bits particulières calculées modulo un très grand nombre premier”, et ça clairement, c’est un algorithme de hachage classique (genre MurmurHash), mais ce n’est clairement pas valable pour un hachage cryptographique.
Après, les histoire de débit de SSD & nvme, c’est juste hors sujet par rapport à ce que je raconte.
D’ailleurs, un algo de hachage classique, tu vas typiquement à la vitesse de lecture des données en mémoire, pas à la vitesse d’un disque.
#6
Et quid de l’algo de hachage Parmentier ?
(Ok, c’est nul
, mais c’est vendredi et je suis fatigué… 
)
#7
Sinon, 7-zip le fait aussi sous windows avec le menu du click droit.
#7.1
Je ne l’avais jamais réalisé, merci!
#8
Sous Linux, plutôt que le vieillissant GtkHash, je préfère Collision 🙂
#8.1
Je ne le connaissais pas merci. Ça s’intègre avec Nautilus ? (Via un clic droit sur un fichier par exemple)
#8.2
Il existe bien une extension pour Nautilus, mais je ne saurais dire pourquoi, elle ne s’est pas installée chez moi. J’ai donc récupéré les sources, histoire de pouvoir récupérer le fichier collision-extension.py que j’ai copié dans $HOME/.local/share/nautilus-python/extensions
Si le paquet n’est pas déjà installé, il faut également nautilus-python
Et pour finir, un petit coup de nautilus -q pour réellement quitter Nautilus (fermer la fenêtre ne suffit pas) et ça devrait être bon.
#8.3
Moi je me suis fait mon propre script qui vérifie md5, CRC32 et SHA256 de plusieurs fichiers à la fois :
À copier dans un fichier à rendre exécutable et à copier dans ~/.local/share/nautilus/scripts/
Il faut installer zenity, md5sum, crc32 et sha256sum s’il ne le sont pas déjà.
#8.4
Merci je vais tester
Merci beaucoup pour ta réponse 😊
#9
Attends j’en ai une autre !
sha256, ça fait beaucoup de croquettes à la fin du mia heuu du mois. non ?
(Je suis déjà loin).
#10
La commande PowerShell Get-FileHash ne se limite pas au Sha256. Via le paramètre -Algorithm, elle peut utiliser les fonctions de hashage suivantes: SHA1, SHA256 (par défaut), SHA384, SHA512, MD5.
Exemple: Get-FileHash .\dvd.iso -Algorithm SHA1
#11
Et est-ce que cet outil t’inspire aussi ? :x
Sinon cet article a été l’occasion d’apprendre que HashTab (qui fonctionne très bien) est obsolète et invite à se tourner vers une alternative comme celle dont vous parlez.
#12
Il est illusoire de penser qu’on peut comparer deux hashs visuellement, il faut utiliser un outil qui gère cette comparaison.
Par exemple, sha256sum a un argument
-cqui permet de lui passer un fichier qui contient une liste de fichiers à vérifier. Pour l’exemple d’une distribution Ubuntu, c’est ce que contient le fichier SHA256SUMS proposé au téléchargement à côté de l’iso. Pas besoin de télécharger tous les fichiers du dossier pour l’utiliser. (Ce n’est pas bien mis en avant sur le site d’Ubuntu, mais c’est là pour Ubuntu 22.04.)#13
Si le titre à perdu Madame Michu, que dire des commentaires
#14
“hashdeep” for the win \o/
Ca permet d’afficher le hash (md5, sha1, sha256…) d’un fichier, de plusieurs fichiers, de tout un répertoire. Mais ça permet aussi de sauver la liste de hash afin de la réutiliser plus tard pour faire des comparaisons, recherches, différences, … Utile pour savoir ce qui a changé dans un répertoire, ou pour comparer deux répertoires.
dispo pour linux, win32 et win64. Open source.
#15
#16
Si le site est piraté pour proposer une ISO avec malware intégré, le hash correspondera probablement : tant qu’à màj l’iso autant prendre quelques minutes pour mettre à jour le hash correspondant :)
#16.1
Qu’est-ce qui permet d’affirmer que c’est rare ? Et si ça l’est, est-ce plus rare que d’avoir uniquement le fichier modifié sur le serveur qui l’héberge ?
Exactement. Le seul cas où je vois un intérêt de vérifier le hash soi-même c’est si le fichier a été modifié ET que c’est seulement la machine qui l’héberge qui a été compromise, ET que c’est pas la même machine que celle qui héberge le site avec le hash et le lien. Sinon, si c’est le site lui-même qui est compromis, le pirate peut très bien changer le hash ET le lien de téléchargement pour qu’il pointe vers le fichier vérolé correspondant au hash.
Bref ça fait beaucoup de si pour que ça ait une utilité…
Ou pas, SHA c’est du hachage cryptographique et c’est très rapide, c’est même le but. La lenteur c’est avant tout pour éviter le brute force il me semble, principalement dans le cas du hachage de mots de passe. Quand on parle de hash de fichier et de collision je suis pas sûr que ça soit la vitesse l’angle d’attaque, plutôt les opérations réalisées et les éventuelles failles qui en découlent.
#17
En général, que ce soit les paquets logiciels ou les fichiers ISO du système, les différentes distributions Linux s’appuient sur tout un réseau de sites miroirs qu’elles ne gèrent pas elles-mêmes. Ça peut être des entreprises ou des universités qui proposent gracieusement de l’espace disque et du trafic réseau. Et leur sécurité peut varier du tout au tout en fonction du pays, de leurs moyens ou de l’importance qu’elles accordent à la sécurité.
Pour les paquets (DEB, RPM…) ces derniers étant signés, le gestionnaire de paquets de la distribution peut s’assurer qu’ils n’ont pas été compris avant de les installer. Mais dans le cas d’ISO de distributions, le système n’ayant pas encore été installé, il n’y aucun mécanisme pour s’assurer qu’il n’y a pas eu compromission, autre que de vérifier soit-même.
#18