Outils de développement · Calculateur de hachage SHA
Hachage cryptographique et somme de contrôle : ce que CRC32 et xxHash ne peuvent pas promettre
· Contexte
sha-256 cryptographie sécurité
CRC32, FNV et xxHash sont également des hachages, mais ils ne font aucune promesse contre un adversaire. Cet article explique ce qui sépare les hachages cryptographiques des sommes de contrôle et comment choisir par cas d'utilisation.
Quel hachage pour quel job ? — le choix entre vitesse et sécurité contradictoire
Les fonctions de hachage se répartissent en trois catégories : les sommes de contrôle pour détecter les erreurs accidentelles, les hachages non cryptographiques pour la distribution et les performances, et les hachages cryptographiques pour la sécurité. Chaque catégorie présente des garanties différentes et des compromis différents en termes de vitesse et de taille de résumé. Une somme de contrôle comme CRC32 est rapide et courte (4 octets, 8 caractères hexadécimaux) mais n'offre aucune protection contre les modifications intentionnelles. Un hachage non cryptographique comme xxHash ou MurmurHash est également rapide et utile pour les tables de hachage et la distribution de données, mais n'offre aucune protection contre un adversaire souhaitant provoquer une collision. Un hachage cryptographique tel que SHA-256 est plus lent et produit un résumé plus long (32 octets, 64 caractères hexadécimaux), mais il offre une résistance à la pré-image et une résistance aux collisions, des propriétés de sécurité qui protègent contre un adversaire.
Choisir la mauvaise fonction de hachage pour votre cas d'utilisation est une erreur de sécurité courante. L'utilisation de CRC32 pour vérifier les téléchargements de fichiers à partir d'une source non fiable est inefficace ; un attaquant peut facilement modifier le fichier et recalculer le CRC32. Utiliser SHA-256 comme fonction de hachage rapide dans une table de hachage haute fréquence est un gaspillage ; CRC32 ou un hachage rapide non cryptographique est suffisant et moins cher.
Sommes de contrôle pour les erreurs accidentelles — Conception du CRC pour détecter les retournements de bits lors de la transmission
Les sommes de contrôle sont conçues pour la détection des erreurs lors de la transmission ou du stockage, où les erreurs sont supposées être aléatoires et accidentelles. CRC (Cyclic Redundancy Check) a été initialement conçu pour détecter les retournements de bits dans la communication. Un CRC32 produit un résumé 32-bit. Si une trame est corrompue par des retournements de bits aléatoires pendant la transmission, le CRC32 changera presque certainement, alertant le récepteur pour qu'il demande une retransmission. CRC peut détecter jusqu'à un certain nombre d'erreurs sur les bits en fonction du polynôme ; pour les cas d'utilisation les plus courants, un retournement de bit unique ou une rafale de retournements de quelques bits est détecté de manière fiable.
CRC est déterministe mais pas cryptographique. Étant donné un fichier et son CRC32, un attaquant peut modifier le fichier et recalculer le CRC32 pour qu'il corresponde à la valeur attendue. Pour un adversaire connaissant le polynôme CRC, fabriquer une collision est simple. Le CRC n’a jamais été destiné à résister à une modification intentionnelle ; c'est uniquement pour la détection d'erreurs accidentelles. Les systèmes historiques tels que les fichiers ZIP et les fichiers JPEG utilisent CRC à cette fin. Les protocoles modernes utilisent le CRC pour une détection rapide des erreurs dans les canaux cryptés ou authentifiés, et non comme un contrôle d'intégrité autonome.
Hachages non cryptographiques pour la distribution — FNV, MurmurHash et xxHash dans les tables de hachage et le partitionnement
Les hachages non cryptographiques comme FNV-1a, MurmurHash et xxHash sont conçus pour la vitesse et l'uniformité des tables de hachage et du partitionnement des données. Ils ont une latence très faible et sont utilisés dans les situations où vous devez partitionner des données sur des serveurs ou des compartiments sans vous soucier des propriétés de sécurité. Si vous créez un cache et devez mapper une clé à un numéro de compartiment, un hachage rapide est approprié. MurmurHash a été conçu explicitement pour l'utilisation de tables de hachage et est plus rapide que SHA sur la plupart des matériels. xxHash est plus récent et optimise les processeurs modernes avec de grands caches et une vectorisation.
Ces hachages ne sont pas cryptographiques car ils ne résistent pas aux attaques de pré-image (trouver une entrée qui produit un résumé spécifique) ou aux attaques de collision (trouver deux entrées différentes qui produisent le même résumé). Un attaquant peut calculer l'algorithme de hachage et trouver les entrées qui entrent en collision ou qui produisent une sortie cible. Dans un environnement de confiance (un cluster où tous les nœuds sont sous votre contrôle), cela est acceptable. Si un utilisateur non fiable peut contrôler l'entrée, un hachage non cryptographique est vulnérable aux attaques par collision qui dégradent les performances (le pire des cas dans la table de hachage est une recherche linéaire lorsque toutes les clés entrent en collision) ou produisent d'autres effets secondaires.
Ce que les hachages cryptographiques ajoutent : pré-image et résistance aux collisions contre un attaquant délibéré
Les hachages cryptographiques comme SHA-256, SHA-384 et SHA-512 fournissent une résistance aux pré-images : étant donné un résumé, il est informatiquement impossible de trouver une entrée qui produit ce résumé. Ils offrent également une résistance aux collisions : il est informatiquement impossible de trouver deux entrées différentes qui produisent le même résumé. Ces propriétés protègent contre un adversaire qui voudrait falsifier un téléchargement, créer un faux certificat ou falsifier un message. Le coût est la vitesse : SHA-256 est plus lent que CRC32 et plus lent que xxHash sur la plupart des matériels.
SHA-1 est cryptographiquement brisé (les collisions sont pratiques) et ne doit pas être utilisé à de nouvelles fins de sécurité, mais il est toujours calculé pour la compatibilité existante. SHA-256, SHA-384 et SHA-512 restent forts et constituent les choix standard pour le hachage cryptographique. Le "2" dans SHA-2 indique la deuxième famille d'algorithmes SHA (la première étant l'original SHA-1 ; SHA-3 est une famille plus récente mais est rarement utilisée à cette fin).
Les hachages cryptographiques ajoutent des propriétés contradictoires ; cet article évite les allégations de vitesse relative non étayées
Faire correspondre cinq scénarios à la bonne famille de hachage : Tout d'abord, les trames réseau transmises sur un canal fiable crypté avec AES : CRC32 est approprié. Le cryptage protège contre les modifications et le CRC détecte les corruptions accidentelles. Deuxièmement, des tables de hachage ou un hachage cohérent pour l'équilibrage de charge : un hachage non cryptographique comme xxHash est approprié. La vitesse compte et l’environnement est digne de confiance. Troisièmement, vérifier l'intégrité du téléchargement à partir d'une source non fiable : SHA-256 est requis. Un attaquant pourrait modifier le fichier et la somme de contrôle, mais pas le hachage cryptographique sans casser SHA-256.
Quatrièmement, signatures et certificats numériques : SHA-256 est requis et est combiné avec un algorithme asymétrique comme RSA ou ECDSA. La signature prouve que le hachage n'a pas été modifié après la signature. Cinquièmement, la déduplication des fichiers téléchargés par l'utilisateur : SHA-256 est requise car les utilisateurs pourraient délibérément télécharger des fichiers conçus pour entrer en collision avec des fichiers existants dans un hachage non cryptographique. Si la déduplication est basée sur xxHash, un attaquant peut télécharger un fichier avec le même hachage qu'un autre fichier mais un contenu différent, ce qui amène le système à rejeter le téléchargement de manière incorrecte.
Exemple concret : faire correspondre cinq scénarios (frames réseau, cartes de hachage, vérification des téléchargements, signatures, déduplication des téléchargements utilisateur) à la bonne famille
Le coût du choix d'un hachage cryptographique pour chaque cas d'utilisation est une surcharge de performances. SHA-256 est plus lent que CRC et plus lent que xxHash. Dans une boucle chaude (un morceau de code qui s'exécute des millions de fois par seconde), cette surcharge est perceptible. En phase de mise en place ou en opération batch, elle est négligeable. Le cadre décisionnel est le suivant : un adversaire est-il incité à provoquer une collision ? Si oui, utilisez SHA-256. Si non, et si la vitesse est importante, utilisez un hachage plus rapide. Si la sécurité est plus importante que la vitesse, utilisez quand même SHA-256.
Une erreur courante consiste à utiliser MD5, un hachage cryptographique plus ancien qui est maintenant cassé. MD5 a été conçu en 1992 et les collisions ont été démontrées en 2004. L’utilisation de MD5 à des fins de sécurité n’est pas sûre. Cela se voit parfois dans les systèmes existants et dans les situations où la vitesse est prioritaire, mais il n'existe aucun scénario dans lequel MD5 soit le bon choix aujourd'hui : si vous avez besoin de vitesse, utilisez xxHash ; si vous avez besoin de sécurité, utilisez SHA-256. N'utilisez jamais MD5.
La cartographie des scénarios reste qualitative car le débit et le comportement des collisions nécessitent des preuves spécifiques à la mise en œuvre.
Le hachage de mot de passe est une quatrième catégorie, distincte des sommes de contrôle et des hachages cryptographiques à usage général. N'utilisez pas SHA-256 pour hacher les mots de passe. Utilisez plutôt une fonction de hachage de mot de passe comme bcrypt, scrypt ou Argon2, qui sont délibérément lentes et incluent un sel. Un hachage cryptographique rapide comme SHA-256 rend la recherche de mot de passe peu coûteuse : un attaquant peut tenter des millions de tentatives par seconde. Une fonction de hachage de mot de passe est conçue pour rendre chaque tentative coûteuse en CPU et en mémoire, de sorte que deviner un mot de passe fort prend toujours plus de temps que n'importe quel attaquant ne peut attendre. Le hachage de mot de passe est un cas d’utilisation spécialisé avec ses propres exigences.
Le calculateur de hachage ToolAcre SHA ne prend pas en charge le hachage de mot de passe et n'offre délibérément aucun MD5, aucun paramètre personnalisé et aucun hachage rapide. Il s'agit d'un outil permettant de calculer des résumés SHA standard pour la vérification et le contrôle d'intégrité, et non pour l'authentification ou le stockage de mots de passe.
À retenir : adversaire ou pas d'adversaire - utilisez le calculateur de hachage ToolAcre SHA lorsque quelqu'un pourrait falsifier les données
Le choix de l'algorithme de hachage est une décision fondamentale qui affecte à la fois les performances et la sécurité de l'ensemble d'un système. Un résumé n’est aussi fiable que l’algorithme qui l’a produit. Si vous choisissez CRC32 pour la vérification des fichiers, le résumé n'offre aucune protection contre les modifications intentionnelles. Si vous choisissez SHA-256 pour une table de hachage, vous gaspillez des ressources. Connaître les propriétés et les compromis de chaque catégorie vous permet de choisir correctement.
Le calculateur de hachage ToolAcre SHA fournit SHA-1 à SHA-512, couvrant les hachages cryptographiques importants pour la plupart des cas d'utilisation. Il ne propose pas CRC32, xxHash ou MD5 car chacun d'entre eux constitue le bon choix dans des contextes spécifiques (CRC pour la détection d'erreurs dans un canal de confiance, xxHash pour les performances dans un environnement contrôlé, rien pour MD5), et les proposer sans insister sur le moment d'utiliser chacun encouragerait les erreurs. La calculatrice sert à calculer des résumés cryptographiques standard. Utilisez la ligne de commande avec `crc32`, `xxh64` ou des outils équivalents si vous avez besoin de ces hachages. Pour la vérification des téléchargements, les empreintes digitales des certificats, les commits git et les cas d'utilisation similaires dans lesquels un adversaire pourrait falsifier les données, accédez à SHA-256 via le calculateur de hachage ToolAcre SHA.