En France, le référentiel général de sécurité (RGS), maintenu par l'ANSSI, fixe les algorithmes de hachage jugés acceptables pour les téléservices de l'administration : SHA-256 et au-delà sont recommandés, tandis que SHA-1 est classé comme obsolète pour toute nouvelle utilisation depuis plusieurs années. Ce référentiel sert souvent de repère, même en dehors du secteur public, pour choisir quel algorithme de contrôle d'intégrité privilégier.
Comment une somme de contrôle détecte une corruption
À cause de l'effet avalanche des fonctions de hachage, même un seul octet corrompu pendant le transfert change complètement le hachage calculé du fichier. Donc toute différence entre la somme de contrôle attendue et celle calculée signifie sans ambiguïté que le fichier diffère de l'original, octet pour octet.
Ce qu'une somme de contrôle ne garantit pas
Une correspondance de hachages confirme seulement que le fichier est identique à celui à partir duquel le hachage publié a été calculé — pas que cet original est sûr ou provient réellement de la source annoncée. Si un attaquant remplace à la fois le fichier et la somme de contrôle publiée (par exemple sur un site compromis), la vérification ne détectera rien.
Somme de contrôle contre signature numérique
Contrairement à une somme de contrôle, une signature numérique est créée avec une clé privée et ne peut être vérifiée qu'avec la clé publique correspondante — l'ANSSI recommande d'ailleurs la signature électronique, et non le simple hachage, dès qu'il faut prouver l'origine d'un document et pas seulement son intégrité. Pour les téléchargements critiques, une signature accompagne donc souvent la somme de contrôle.
Pourquoi c'est utile
- Confirmer qu'une archive ou une image système téléchargée n'a pas été corrompue pendant le téléchargement.
- Comparer rapidement deux gros fichiers sans les comparer octet par octet.
- Vérifier qu'une copie de sauvegarde d'un fichier est identique à l'original.
Pourquoi on utilise parfois CRC32 au lieu de SHA-256
CRC32 est bien plus rapide que les fonctions de hachage cryptographiques, mais il est facile à falsifier délibérément — ce n'est pas un problème pour détecter une corruption accidentelle pendant le transfert, mais il est inadapté comme protection contre un attaquant qui veut remplacer un fichier discrètement. C'est pourquoi CRC32 se retrouve encore dans les archiveurs et les protocoles réseau pour le contrôle d'erreurs, mais jamais dans un référentiel de sécurité comme le RGS.