Aller au contenu
HexaTransfer
Retour au blog
Chiffrement et securite

Fonctions de hachage expliquées : vérifier l'intégrité

Les fonctions de hachage sont essentielles pour vérifier l'intégrité après transfert. Apprenez comment SHA-256 et MD5 garantissent vos fichiers intacts.

Une fonction de hachage prend n'importe quelle entrée et produit une sortie de taille fixe — SHA-256 génère toujours exactement 256 bits (32 octets) que l'entrée soit un tweet ou une vidéo de 10 Go. Modifiez un seul bit en entrée, et environ la moitié des bits de sortie basculent. Cette propriété déterministe et à sens unique fait des hachages l'outil de référence pour vérifier l'intégrité des fichiers : calculez SHA-256(fichier) avant l'envoi, recalculez-le après réception, et si les hachages correspondent, le fichier est arrivé intact. C'est ainsi que les distributions Linux vérifient les téléchargements d'ISO, que Git identifie les commits, et que des services comme HexaTransfer confirment que les envois de plusieurs gigaoctets se terminent sans corruption.

Ce que garantit une fonction de hachage

Trois propriétés définissent une fonction de hachage cryptographique :

  • Déterministe. Une même entrée produit toujours la même sortie. SHA-256("bonjour") est toujours identique.
  • Résistance à la préimage. Connaissant un hachage, il est impossible de retrouver efficacement l'entrée qui le produit.
  • Résistance aux collisions. Il est impossible de trouver efficacement deux entrées différentes produisant le même hachage.

Et deux comportements utiles :

  • Effet avalanche. Modifier un seul bit en entrée modifie environ 50 % des bits de sortie. Inutile pour la recherche, idéal pour l'empreinte numérique.
  • Taille de sortie fixe. SHA-256 produit 32 octets, SHA-512 produit 64 octets, BLAKE2b produit 64 octets, quelle que soit la taille de l'entrée.

Les hachages ne sont pas du chiffrement. Ils fonctionnent à sens unique — vous ne pouvez pas retrouver l'entrée à partir de la sortie. C'est précisément l'objectif.

La famille SHA

La famille Secure Hash Algorithm, standardisée par le NIST dans FIPS 180-4 et FIPS 202 :

  • SHA-1 — 160 bits, compromis par l'attaque SHAttered de Google en 2017. À ne pas utiliser pour la sécurité.
  • SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512). Le cheval de bataille des systèmes modernes. SHA-256 domine.
  • SHA-3 (Keccak). Construction différente (éponge, et non Merkle-Damgård), standardisée en 2015 comme solution de secours contre d'éventuelles faiblesses de SHA-2 qui ne se sont pas concrétisées.

SHA-256 est ce que signent les certificats TLS, ce que mine Bitcoin, ce qu'utilise Git (une transition vers SHA-256 est encore en cours), et ce que les services de transfert de fichiers calculent pour les vérifications d'intégrité. Débit sur les CPU modernes avec extensions SHA : 2 à 4 Go/s par cœur.

Pourquoi MD5 et SHA-1 ne conviennent plus à la sécurité

MD5 (1991) produit des hachages de 128 bits et était le standard jusqu'à ce que des collisions soient démontrées en 2004. En 2012, le malware Flame a forgé des certificats de signature de code Microsoft en exploitant une attaque par collision MD5. Aujourd'hui, vous pouvez générer des collisions MD5 en quelques secondes sur un ordinateur portable.

SHA-1 a résisté plus longtemps mais a cédé face à l'attaque SHAttered de Google en 2017, qui a produit deux PDF avec des hachages SHA-1 identiques après 110 années-GPU de calcul — désormais reproductible pour moins de 100 000 € sur des GPU cloud.

Les deux restent acceptables pour des usages non liés à la sécurité : détecter une corruption accidentelle, dédupliquer le stockage, créer des empreintes de clés de cache. Ils ne conviennent pas pour les signatures numériques, la vérification de mots de passe, ou tout scénario où un attaquant tire avantage d'une correspondance forgée.

BLAKE2 et BLAKE3 : vitesse et sécurité réunies

BLAKE2 (2012) et BLAKE3 (2020) offrent une sécurité au niveau de SHA-3 avec une vitesse 2 à 10 fois supérieure à SHA-256. BLAKE3 atteint environ 6 Go/s en monothread et se parallélise linéairement sur plusieurs cœurs — une machine à 16 cœurs peut dépasser les 100 Go/s.

L'adoption progresse : WireGuard utilise BLAKE2s pour l'authentification, Zcash utilise BLAKE2b, et b3sum devient un remplacement courant de sha256sum dans les outils pour développeurs. Les services de transfert de fichiers traitant des envois de plusieurs gigaoctets adoptent de plus en plus BLAKE3 pour éviter que le calcul de hachage ne devienne le goulot d'étranglement.

Les navigateurs n'exposent pas encore BLAKE3 via l'API Web Crypto, de sorte que les implémentations JavaScript s'appuient sur du code de référence compilé en WASM, atteignant environ 500 Mo/s dans le navigateur.

Les hachages dans les flux de transfert de fichiers

Plusieurs cas où les hachages font leurs preuves :

  • Vérification d'intégrité après envoi. Le client calcule le SHA-256 lors de l'envoi, le serveur le recalcule à l'arrivée ; toute divergence déclenche un renvoi. S3 utilise MD5 pour cela, car la vitesse prime sur la résistance aux collisions face à une corruption passive.
  • Vérification des envois fragmentés. Les grands fichiers sont découpés en fragments de 4 ou 5 Mo ; chaque fragment reçoit un hachage, et un arbre de hachages (arbre de Merkle) produit un hachage racine unique pour l'ensemble du fichier.
  • Déduplication. Si deux utilisateurs envoient le même fichier, les hachages correspondent et le stockage ne conserve qu'une copie. Utilisé par la déduplication bloc de Dropbox et le cache CDN.
  • Vérification du téléchargement. Certains services affichent le SHA-256 sur la page de téléchargement pour que les destinataires puissent vérifier.
  • Identification de version. Git utilise SHA-1 (migration vers SHA-256 en cours) pour les identifiants de commits — le contenu d'un fichier détermine son identité.

L'extension HMAC

Les hachages simples vérifient l'intégrité mais pas l'authenticité — n'importe qui peut calculer SHA-256(fichier). Ajouter une clé secrète transforme un hachage en code d'authentification de message (MAC) : seul celui qui possède la clé peut produire ou vérifier le MAC.

HMAC (RFC 2104) est la construction standard : HMAC(clé, msg) = SHA-256(clé' ⊕ opad || SHA-256(clé' ⊕ ipad || msg)). Utilisé dans TLS 1.2, les JWT signés avec HS256, la signature des requêtes AWS, et de nombreux schémas de cookies de session.

Pour le transfert de fichiers, HMAC apparaît dans le tag d'authentification d'AES-GCM (qui utilise GHASH, pas HMAC, mais remplit le même rôle) et dans la signature des requêtes API de certains services.

Les arbres de Merkle : hachage à grande échelle

Pour les très grands fichiers ou collections de fichiers, recalculer le hachage de l'ensemble à chaque fois est peu efficace. Un arbre de Merkle organise les hachages en arbre binaire : les feuilles sont les hachages des fragments, les nœuds internes sont les hachages de leurs enfants, et le hachage racine représente l'ensemble des données.

Avantages :

  • Mises à jour efficaces. Modifier un fragment ne nécessite de recalculer que log(n) nœuds.
  • Preuve d'inclusion. Il est possible de prouver qu'un fragment spécifique fait partie de la racine avec seulement log(n) hachages frères.
  • Calcul parallèle. Les branches se hachent indépendamment.

Utilisés par BitTorrent (post-v2), l'adressage de contenu IPFS, les objets arbre de Git, les journaux de transparence des certificats, et les racines de transactions blockchain. Les services de transfert utilisent les arbres de Merkle pour les envois reprenables, où les téléchargements partiels doivent être vérifiés par rapport à l'original.

Mots de passe et hachages

Les hachages servent aussi à transformer les mots de passe en valeurs sûres pour le stockage. Un simple SHA-256(motdepasse) est insuffisant — les fermes de GPU calculent des milliards de SHA-256 par seconde, faisant tomber instantanément tout mot de passe courant.

Les hachages spécifiques aux mots de passe ajoutent un coût de calcul :

  • PBKDF2-HMAC-SHA-256 avec 600 000 itérations (OWASP 2023).
  • bcrypt avec un facteur de coût 12 (environ 250 ms par hachage).
  • scrypt avec durcissement mémoire pour résister aux GPU.
  • Argon2id — meilleure pratique actuelle, résistant à la mémoire et au parallélisme.

L'objectif n'est pas la sécurité via le hachage lui-même — c'est de rendre chaque tentative suffisamment coûteuse pour que la force brute hors ligne devienne impraticable pour tout mot de passe non trivial.

Vérifier un téléchargement à la main

N'importe quel fichier important peut être vérifié avec des outils en ligne de commande. Sur macOS ou Linux :

shasum -a 256 ubuntu-24.04.iso

Sur Windows PowerShell :

Get-FileHash ubuntu-24.04.iso -Algorithm SHA256

Comparez le résultat avec le hachage publié sur ubuntu.com. S'ils correspondent, le fichier a été téléchargé intact et correspond à ce que Canonical a signé. S'ils diffèrent, le téléchargement a été corrompu ou quelqu'un a substitué le fichier.

Pour une confiance maximale, vérifiez la signature du fichier de hachage lui-même avec GPG et la clé de signature de Canonical. La chaîne à plusieurs étapes — fichier de hachage signé → hachage du fichier → fichier — est la façon dont les distributions Linux maintiennent la confiance depuis des décennies.

Évaluer la gestion de l'intégrité d'un service de transfert

Quatre questions à poser à tout prestataire de transfert de fichiers :

  • Quel algorithme de hachage utilisez-vous pour vérifier les envois ? (SHA-256 ou BLAKE3 conviennent ; MD5 est tolérable pour les seules vérifications de corruption ; le silence est un signal d'alerte.)
  • Affichez-vous le hachage au destinataire ? (Pas tous, mais c'est appréciable.)
  • Pour les envois fragmentés, utilisez-vous un arbre de Merkle ?
  • Existe-t-il un moyen de comparer les hachages entre les deux extrémités ?

SwissTransfer, Tresorit, Proton Drive et HexaTransfer calculent tous le SHA-256 lors du transfert et le vérifient à l'arrivée. Les échecs d'intégrité déclenchent un renvoi automatique des fragments concernés plutôt que l'échec de l'ensemble du transfert.

Mise en pratique

Pour votre prochain transfert sensible : calculez shasum -a 256 fichier.pdf avant l'envoi, conservez le hachage, et demandez au destinataire de faire de même après le téléchargement. Des hachages identiques prouvent une intégrité octet par octet. C'est 30 secondes de travail qui détectent la corruption, la falsification, et le CDN mal configuré à l'occasion.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.

Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout

Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.

Envoyer un fichier