Somme de contrôle
Saisissez un texte, et les sommes de contrôle sont calculées avec quatre méthodes à la fois.
0 Caractères · 0 Octets
Sommes de contrôle
- SHA-1160 bits
Écrivez quelque chose dans le champ ci-dessus.
- SHA-256256 bits
Écrivez quelque chose dans le champ ci-dessus.
- SHA-384384 bits
Écrivez quelque chose dans le champ ci-dessus.
- SHA-512512 bits
Écrivez quelque chose dans le champ ci-dessus.
Le texte ne quitte jamais votre navigateur. Le calcul emploie la fonction cryptographique du navigateur lui-même.
Comment ça marche
Une somme de contrôle cryptographique transforme un texte de longueur quelconque en un nombre fixe de caractères. Le même texte donne toujours la même somme, alors que le plus petit changement en donne une tout autre.
La fonction ne va que dans un sens. Il n’y a pas de chemin de retour de la somme vers le texte, et c’est précisément son but.
Les sommes de contrôle servent à comparer des fichiers, à repérer les modifications, et de brique dans les signatures et les certificats.
SHA-1 n’est plus considéré comme sûr. Depuis 2017, il existe des moyens praticables de produire deux textes différents ayant la même somme SHA-1 : ne l’employez donc que pour dialoguer avec des systèmes plus anciens.
Les mots de passe ne se conservent pas avec ces fonctions. Elles sont bâties pour la vitesse, ce qui rend facile de les essayer en masse. Pour les mots de passe, on emploie des méthodes délibérément lentes comme Argon2id, scrypt et PBKDF2. L’OWASP ne recommande bcrypt que pour les systèmes anciens où ni Argon2id ni scrypt ne sont disponibles.
Le texte est encodé en UTF-8 avant le calcul, si bien que les lettres accentuées donnent ici la même somme que dans d’autres outils corrects.
Comment l’outil fonctionne
Le texte est converti en UTF-8 et transmis à la fonction crypto.subtle.digest du navigateur, qui calcule d’un coup SHA-1, SHA-256, SHA-384 et SHA-512. Les empreintes s’écrivent en hexadécimal minuscule, deux caractères par octet : 40 caractères pour SHA-1, 64 pour SHA-256, 96 pour SHA-384 et 128 pour SHA-512. Elles sont recalculées à chaque caractère saisi.
Les mêmes octets donnent toujours la même empreinte dans tout outil correct, mais le même texte peut devenir des octets différents. En UTF-8, la lettre é fait deux octets, C3 A9, alors que dans l’ancien codage Latin-1 elle n’en fait qu’un, E9. Un mot accentué donne donc ici une autre empreinte que dans un programme qui travaille en Latin-1.
Exemple détaillé
Le texte abc donne l’empreinte SHA-256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad, la valeur que le NIST donne dans son exemple de test de l’algorithme. Si abc est suivi d’un retour à la ligne, comme en ajoute la commande echo, l’empreinte devient edeaaff3f1774ad2888673770c6d64097e391bc362d7d6fb34982ddf0efd18cb. Le retour à la ligne ne se voit pas dans le texte, mais l’empreinte est une autre.
Cas limites
L’outil calcule l’empreinte d’un texte, pas d’un fichier. La somme de contrôle d’un fichier téléchargé se calcule sur les octets du fichier, par exemple avec certutil -hashfile sous Windows ou sha256sum sous Linux. Coller le contenu du fichier ne donne la même empreinte que si le texte est identique octet pour octet.
Les fins de ligne sont la cause la plus fréquente d’empreintes qui ne concordent pas. Le HTML Standard impose à une zone de texte de convertir chaque fin de ligne en LF seul : un texte venu d’un fichier aux fins de ligne Windows, CR LF, obtient ici une autre empreinte que dans certutil. Les espaces en fin de ligne et un dernier retour à la ligne comptent aussi.
Le 15 décembre 2022, le NIST a annoncé que SHA-1 doit être abandonné d’ici au 31 décembre 2030 au profit de SHA-2 ou SHA-3. Parmi les fonctions proposées ici, SHA-256, SHA-384 et SHA-512 appartiennent à SHA-2.