Pourquoi Web Crypto propose SHA-1 à SHA-512 mais pas MD5 ou SHA-3

Où est MD5 ? — la première question de toute personne migrant un workflow de somme de contrôle hérité

L'API Web Crypto du navigateur contient exactement quatre algorithmes de résumé : SHA-1, SHA-256, SHA-384 et SHA-512. Si vous recherchez le calculateur de hachage ToolAcre SHA en attendant MD5 ou SHA-3, vous ne les trouverez pas. Cette spécificité ne constitue pas une limitation de l’outil ; cela reflète un choix délibéré de plateforme. Comprendre pourquoi ces quatre éléments ont été inclus et pourquoi deux alternatives populaires ont été laissées de côté vous en dit long sur la façon dont les API des navigateurs sont conçues.

Tous les principaux navigateurs exposent crypto.subtle.digest sur des origines sécurisées. Lorsque votre JavaScript appelle cette méthode, elle passe à l'implémentation cryptographique de la plate-forme : un code natif exécuté avec un sandboxing de sécurité et une optimisation des performances. Les algorithmes de résumé proposés ont été choisis par le groupe de travail Web Crypto du W3C avec des priorités spécifiques : compatibilité avec les normes de sécurité existantes, prise en charge disponible dans les bibliothèques cryptographiques, maturité et besoins pratiques de sécurité de la plate-forme Web.

Les quatre algorithmes pris en charge par SubtleCrypto.digest : SHA-1, SHA-256, SHA-384 et SHA-512, et rien d'autre

ToolAcre accepte les quatre mêmes identifiants appliqués par digestBytes : SHA-1, SHA-256, SHA-384 et SHA-512. Un nom non reconnu est rejeté avant l'appel de Web Crypto, et la suite de tests passe spécifiquement MD5 pour confirmer ce rejet. Le préparateur décrit donc une frontière de produit testée plutôt qu'une étude de chaque résumé jamais standardisé.

SHA-1 apparaissant dans cette liste ne fait pas les quatre recommandations équivalentes. Son objet résultat porte un indicateur brisé et l'interface répète un avertissement hérité ; les trois autres sont les choix SHA-2 disponibles. La disponibilité et l'adéquation doivent rester séparées chaque fois qu'un outil de compatibilité reproduit une ancienne valeur sans encourager une nouvelle dépendance à son égard.

MD5 est absent de cette implémentation et de Web Crypto ; cet article n'ajoute pas de justification de normes non sourcées

MD5 est une fonction de hachage cryptographique qui produit un résumé 128 bits, le rendant plus court et moins coûteux en termes de calcul que SHA-256. Pendant des décennies, il s’agissait du choix standard pour les sommes de contrôle et les signatures numériques. Cependant, la résistance aux collisions du MD5 est fondamentalement brisée. Dans 2004, les cryptographes ont démontré des collisions pratiques (deux entrées différentes avec le même résumé) et l'algorithme a été complètement démantelé par des travaux universitaires. La vulnérabilité mathématique est absolue et permanente.

La spécification W3C Web Crypto a fait un choix délibéré de ne pas inclure MD5. Le raisonnement est simple : transmettre un algorithme défectueux à des millions d’utilisateurs de navigateurs normaliserait son utilisation dans de nouvelles applications, même s’il ne devrait apparaître que dans des scénarios de compatibilité existants. Si une application nécessite réellement MD5 pour l'interopérabilité avec les anciens systèmes, ce code appartient à un environnement d'exécution côté serveur où l'exigence est comprise et auditée, et non dans le navigateur. Rendre facilement accessible un algorithme défectueux créerait des attentes en matière de sécurité dans les nouveaux systèmes.

Le calculateur de hachage ToolAcre SHA ne fournit pas non plus d'implémentation MD5. Comme l’API de la plateforme qu’il utilise, il refuse de rendre facilement accessible un algorithme défectueux. Si votre application nécessite absolument MD5 (rare en dehors des systèmes Git existants), l'implémentation appartient à votre propre base de code avec une note claire qu'il s'agit d'une cale de compatibilité. L'accessibilité crée des attentes, et les algorithmes défectueux ne méritent aucune attente.

SHA-3 est en dehors de l'API du navigateur et de l'outil ; son historique d'adoption est en dehors des preuves du référentiel

SHA-3 a été standardisé par le NIST en 2015 après un long concours public, et il est cryptographiquement solide. Il utilise une construction fondamentalement différente de SHA-2, appelée éponge, qui offre des propriétés théoriques intéressantes et des compromis de performances en fonction de votre matériel. Sur les systèmes modernes, SHA-3 peut être plus rapide que SHA-256. Pourtant, la plateforme du navigateur ne l’expose pas aujourd’hui, et ce retard reflète des décisions pratiques concernant la maturité de la plateforme et le rythme de son adoption.

Le retard d'expédition SHA-3 reflète la réalité : Web Crypto a été conçu pour couvrir les algorithmes les plus largement utilisés sur le Web et dans HTTPS/TLS. Lors de la finalisation de l'API, SHA-2 (256, 384, 512) constituait le consensus écrasant pour les nouveaux systèmes, et le passage à SHA-3 se produit beaucoup plus lentement que le passage de MD5 ou SHA-1. La plupart des applications n'ont pas encore besoin de SHA-3. Le coût de l’extension de l’API et de son test sur tous les navigateurs et plates-formes n’était pas justifié par la demande au lancement.

Il ne s’agit pas d’un rejet permanent. L’API Web Crypto peut évoluer. Si l’adoption de SHA-3 s’accélère, le groupe de travail pourrait l’ajouter. L'ensemble actuel représente les algorithmes matures et largement standardisés dont Web Crypto a besoin pour répondre aux besoins immédiats de sécurité de la plate-forme. Les API du navigateur doivent être stables et soigneusement entretenues ; se précipiter pour ajouter des fonctionnalités avant que le besoin ne se généralise crée une charge de maintenance et un risque de compatibilité pour les années à venir.

Pourquoi SHA-1 est toujours là : besoins de vérification existants et différence entre offrir et recommander

SHA-1 est inclus dans Web Crypto bien qu'il soit cryptographiquement cassé. Ce choix contre-intuitif surprend souvent les développeurs. L'algorithme produit un résumé 160 bits, et les attaques par collision contre SHA-1 sont désormais pratiques : deux documents différents peuvent être créés pour partager le même résumé. Les collisions de préfixes choisis permettent aux attaquants de créer deux documents qui sont tous deux significatifs lors de la collision, ce qui brise les signatures et les certificats. Pourtant, il reste dans la plateforme.

SHA-1 reste dans Web Crypto pour une raison nécessaire : la compatibilité héritée. Les identifiants d'objet Git sont basés sur SHA-1, et pendant que le projet Git est en transition vers SHA-256, des millions de référentiels, de références et de systèmes de build existants émettent toujours des hachages SHA-1. Les empreintes digitales des certificats TLS des systèmes plus anciens contiennent des résumés SHA-1. Les API qui ont émis des signatures HMAC-SHA1 il y a des années doivent encore être validées. Ces systèmes déployés doivent être vérifiés ou migrés. La plate-forme comprend SHA-1 pour rendre possible ce travail nécessaire.

L'API de la plate-forme inclut SHA-1, étant clairement entendu qu'elle est là pour la compatibilité et non pour la recommandation. L'interface utilisateur du navigateur étiquette SHA-1 avec un avertissement. Le calculateur de hachage ToolAcre SHA affiche « Cryptographiquement cassé » à côté du résultat SHA-1, garantissant que toute personne qui l'utilise comprend qu'elle travaille avec du matériel existant. La transparence est essentielle ; les utilisateurs ne doivent jamais confondre la compatibilité SHA-1 avec l'approbation de SHA-1.

Si la compatibilité nécessite MD5, utilisez une implémentation révisée en dehors de cet outil et ne confondez jamais compatibilité et sécurité

Les quatre algorithmes de Web Crypto s'alignent sur l'écosystème de la suite de chiffrement TLS et sur les normes de sécurité les plus importantes. SHA-256 est la valeur par défaut actuelle pour le hachage à usage général, utilisé dans les contrôles d'intégrité des sous-ressources, l'adressage de contenu et les nouveaux systèmes de sécurité. SHA-512 est plus rapide sur le matériel 64 bits et offre un résumé plus large. SHA-384 est principalement connu pour son utilisation dans les suites de chiffrement TLS.

SHA-1 est conservé à des fins d'interopérabilité, et non parce que quiconque devrait démarrer un nouveau système avec. Si vous vérifiez une somme de contrôle SHA-1 existante, faites correspondre une ancienne empreinte digitale de certificat ou reproduisez un ID de validation Git, SHA-1 dans ToolAcre vous permet de le faire. Si vous concevez un nouveau système, SHA-256 est le choix évident. L'algorithme que vous choisissez indique votre compréhension du modèle de sécurité.

Ce que cela ne couvre pas : les environnements d'exécution côté serveur, qui exposent généralement beaucoup plus d'algorithmes de synthèse

Si votre application a vraiment besoin de MD5, SHA-3 ou de tout autre algorithme, le choix est clair : conserver ce code dans le runtime côté serveur et exposer uniquement le résultat final au navigateur. N'envoyez pas votre propre implémentation JavaScript d'un algorithme cryptographique pour une utilisation dans le navigateur. Le Web Crypto natif du navigateur est plus rapide, plus sûr et audité d'une manière qu'une fonction JavaScript écrite à la main ne peut égaler. Déléguer à la plateforme est toujours le bon choix lorsque la plateforme fournit ce dont vous avez besoin.

Cela s'applique même aux algorithmes "simples". Une implémentation MD5 auto-écrite peut sembler inoffensive car MD5 est de toute façon cassé, mais les algorithmes défectueux n'ont pas de gradations : ils sont simplement cassés. Shipping One normalise la pratique de mise en œuvre de la cryptographie dans le code d’application. Le navigateur fournit ce dont la plateforme a besoin ; utiliser ce qu'il fournit. La cryptographie manuelle est la plus grande source de vulnérabilités de sécurité dans les applications Web, car les développeurs sous-estiment la subtilité et les cas extrêmes.

À retenir : les limitations font partie du produit – le calculateur de hachage ToolAcre SHA propose les quatre algorithmes que le navigateur implémente de manière native et documente ces limites.

Le calculateur de hachage ToolAcre SHA fait directement apparaître cette contrainte : vous voyez exactement les quatre algorithmes fournis par Web Crypto, ni plus ni moins. Si vous collez une valeur et pensez « J'ai besoin de MD5 », l'absence est intentionnelle. Si vous en avez besoin, cela indique que votre système dispose d'un composant existant qui nécessite une manipulation minutieuse - exactement le genre de chose à laquelle sert un outil de migration spécialisé côté serveur, et non un utilitaire de navigateur. L'honnêteté de l'outil sur ce qu'il fait et ce qu'il n'offre pas est en soi une information précieuse.

La conception de Web Crypto reflète des décennies de pratique cryptographique : des algorithmes standardisés, audités et éprouvés dans un déploiement à grande échelle. SHA-256 et SHA-512 sont les valeurs par défaut raisonnables. SHA-384 porte sa lignée TLS. SHA-1 est là parce que le Web contient des résumés SHA-1 qui devront être vérifiés pendant des années. MD5 et SHA-3 ne sont pas là car MD5 est cassé et SHA-3 n'est pas encore critique pour la plate-forme.