Vérificateur de hash de fichier

Comment l’outil vérifie-t-il l’intégrité des fichiers ?

Une fonction de hash cryptographique projette toute entrée — qu’elle fasse 12 octets ou 12 gigaoctets — sur une courte valeur hex de longueur fixe. Si un seul octet change en entrée, le hash change presque entièrement. Cela fait des hashs la méthode standard pour l’intégrité : un éditeur publie le hash d’un fichier, vous le recalculez localement après téléchargement, et si les deux valeurs coïncident, le fichier est inchangé depuis la publication.

Nous calculons dans le navigateur via une couche de hashing accélérée par WASM, incrémentale. Incrémentale signifie : le fichier n’est pas chargé d’un coup en RAM ; il est lu en chunks de 64 Ko via File.stream() et passé pas à pas au hasher. À la fin, une seule valeur hex en sort. C’est ce pipeline qui permet les fichiers de plus de 2 Go — l’API standard du navigateur n’y parvient pas.

Que signifient SHA-256, SHA-512, MD5, SHA-1 et BLAKE3 ?

SHA-2 est la famille de fonctions cryptographiques spécifiée par le NIST américain dans le standard FIPS 180-4. SHA-256 produit un digest de 256 bits (64 caractères hex) et est aujourd’hui le standard de facto pour les releases logicielles, les téléchargements d’ISO Linux, les images de conteneurs et les blockchains. SHA-512 est la variante longue à digest de 512 bits (128 caractères hex) — même construction mathématique, espace de sortie plus grand.

SHA-1 (160 bits, 40 caractères hex) et MD5 (128 bits, 32 caractères hex) sont plus anciens. MD5 a été déclaré cryptographiquement cassé en 2004, SHA-1 en 2017. Pour des contrôles d’intégrité purs (objets Git, clés de cache, versionnement de fichiers) ils sont encore acceptables ; pour les vérifications de sécurité — partout où un attaquant doit pouvoir forger un autre fichier de même hash — non.

BLAKE3 est un standard moderne de 2020. Il produit un digest de 256 bits comme SHA-256, mais est nettement plus rapide, cryptographiquement sûr et parallélisable. Il est adopté de plus en plus dans les outils de build et les content-addressable stores. Pour les téléchargements distributeurs, il n’est pas encore le standard de facto, mais reste pertinent — nous le proposons à qui en a besoin.

Quand quel algorithme est-il le bon choix ?

Si l’éditeur publie un seul hash sans préciser l’algorithme, déduisez-le de la longueur hex : 32 caractères = MD5, 40 = SHA-1, 64 = SHA-256 (ou plus rarement BLAKE3 — généralement précisé dans un sidecar ou une note distributeur), 128 = SHA-512. L’outil détecte la longueur automatiquement et propose l’algorithme adapté ; à 64 caractères, un toggle SHA-256/BLAKE3 apparaît car les deux produisent 64 caractères.

En génération, la recommandation est pragmatique : SHA-256 suffit partout pour le contrôle d’intégrité moderne. En conformité d’audit ou contexte administratif, on ajoute SHA-512. BLAKE3 vaut le coup si le destinataire le comprend aussi (sinon, le hash plus rapide est inutile). MD5 et SHA-1 ne sont générés que si la partie réceptrice l’exige explicitement — par ex. anciens pipelines CI ou formats de manifest legacy.

Calculer plusieurs algorithmes en parallèle ne coûte que +5 à 15 % de temps par algo, car les octets ne sont lus qu’une fois — utile quand on ne sait pas lequel le destinataire attend.

En quoi diffèrent Générer, Vérifier et Comparer ?

Générer est le mode « j’ai besoin de nouveaux hashs ». Un ou plusieurs fichiers en entrée, tous les algorithmes sélectionnés sont calculés en parallèle, le résultat est un tableau avec une ligne par fichier. Utile pour la création de manifests distributeur, listes d’audit de sauvegarde ou simplement pour obtenir le SHA-256 d’un fichier. L’export CSV écrit le tableau dans un format directement ouvrable dans Excel.

Vérifier est le mode « ce fichier correspond-il à ce hash attendu ? » Un fichier plus une valeur attendue (collée ou par drop de sidecar) — l’outil calcule, compare et affiche une bannière de match ou de mismatch avec diff surligné. Précisément le cas d’usage derrière le terme « vérificateur de hash de fichier » et qui chez la concurrence reste souvent secondaire voire absent.

Comparer est le mode « ces deux fichiers sont-ils vraiment identiques ? » Deux fichiers en entrée, tous deux hashés en parallèle pour les algorithmes choisis, le résultat est une bannière (« fichiers identiques » ou « fichiers différents ») plus un tableau par algorithme. Utile après restauration, retéléchargement, migration de disque ou comparaison de sync cloud.

Pourquoi les très gros fichiers fonctionnent-ils ici et pas ailleurs ?

L’API standard du navigateur attend le fichier entier comme un seul objet mémoire. Sur Firefox, cette API refuse les entrées de plus de 2 Go avec une TypeError — très concrètement documenté dans des trackers open-source où des outils de sauvegarde ou de synchronisation crashent sur de gros fichiers médias. Les autres navigateurs ont le même problème à des degrés divers, parce que la limite mémoire d’un onglet finit par être atteinte.

Nous contournons cela avec un hasher WebAssembly incrémental : init() démarre un état neuf, update(chunk) l’alimente avec le chunk suivant, digest() clôt et fournit la valeur hex. Le chemin de lecture utilise File.stream().getReader(), API navigateur standard, qui livre les octets en flux sans charger en RAM. La consommation mémoire reste sous 100 Mo, que le fichier fasse 100 Mo ou 100 Go.

À quoi l’outil convient-il — et à quoi non ?

Convient : vérification de téléchargement logiciel contre des hashs publiés, validation post-restauration, génération de manifest distributeur, vérification de sync cloud, aide forensique pour « ce fichier est-il vraiment celui que j’avais il y a deux semaines ? », listes d’audit rapides pour dossiers photo/vidéo.

Ne convient pas : authentification (c’est HMAC + clé, pas hash de fichier), stockage de mots de passe (c’est Argon2/bcrypt/scrypt), protection contre un éditeur compromis (voir disclaimer ci-dessous), preuve de sécurité unique avec MD5 ou SHA-1 (plus recommandés pour les vérifications de sécurité).

Avertissement important sur la vérification de hash : un hash correct prouve seulement que le fichier est inchangé depuis la publication du hash — il ne prouve pas que la source est digne de confiance. Comparez donc le hash avec une source indépendante (notes de version, entrées de mailing-list signées, gestionnaire de paquets officiel), pas seulement la valeur affichée à côté du téléchargement.

Quels outils s’y rapportent ?

Dans l’écosystème kittokit, thème vérification de fichiers et intégrité des données :

• Générateur de hash — hashe du texte au lieu de fichiers. Utile pour mots de passe, tests JWT secret ou hashs d’API.
• Décodeur JWT — décoder les JSON Web Tokens, utile pour la vérification de tokens signés (complémentaire des hashs de fichiers).
• Générateur d’UUID — produire des identifiants uniques, utile pour ses propres manifests ou jeux de données de test.