Un fournisseur publie un installeur avec un SHA-256 à côté du lien de téléchargement. Un client vous envoie un fichier de config par courriel et dit « voici exactement ce qu’il y a en production ». Une archive de sauvegarde arrive sur un hôte distant et vous voulez prouver que les octets reçus correspondent aux octets envoyés. Les trois posent la même question : ces deux choses — celle que j’ai et celle qu’un autre a — sont-elles réellement identiques, octet pour octet ? Le générateur de hachages de PortJar répond à ça sans rien installer.
Ce que l’outil fait
Le générateur de hachages prend n’importe quel texte en entrée et retourne quatre hachages en une seule passe : MD5, SHA-1, SHA-256 et SHA-512. Il s’exécute entièrement côté client — l’entrée ne quitte jamais l’onglet du navigateur — ce qui veut dire que vous pouvez hacher des secrets, des valeurs de config internes ou des charges utiles sensibles sans craindre une journalisation côté serveur.
Les quatre algorithmes ne sont pas interchangeables. MD5 et SHA-1 sont rapides et compacts, mais cryptographiquement cassés ; on peut fabriquer des collisions sur commande. Ils restent corrects pour des sommes de contrôle non adverses — confirmer qu’un téléchargement n’a pas été corrompu en transit, comparer deux versions d’un fichier de config, indexer un cache. SHA-256 et SHA-512 sont plus lents, plus longs, et considérés actuellement comme résistants aux collisions ; utilisez-les partout où un attaquant tirerait avantage d’une correspondance forgée (signature, adressage par contenu, déduplication où deux entrées distinctes produisant le même hachage causeraient des dommages).
Comment l’utiliser
Ouvrez portjar.com/tools/hash-generator, collez le texte, appuyez sur Run, et les quatre hachages apparaissent ensemble. Les puces d’exemple chargent hello world et The quick brown fox si vous avez besoin d’une vérification rapide que la sortie de l’algorithme correspond à ce qu’un manuel ou une commande shell produirait. Pour comparer au hachage publié par un fournisseur, copiez la sortie de l’algorithme pertinent et faites le diff avec ce qu’il a publié — caractère par caractère, pas à l’œil.
Pour hacher des fichiers réels plutôt que du texte, l’outil n’est pas la bonne forme — collez la représentation textuelle d’une valeur, pas un fichier binaire. Pour les fichiers, lancez sha256sum (Linux), shasum -a 256 (macOS) ou Get-FileHash (PowerShell) localement ; les algorithmes sont identiques, seule la source de l’entrée diffère.
Quand y recourir
- Vérifier un installeur ou une image fournis par un éditeur contre le SHA-256 qu’il a publié, avant de l’exécuter sur un hôte de production. Un écart, c’est soit un téléchargement corrompu, soit, dans le pire des cas, un remplacement par interception ; dans les deux cas, vous ne l’exécutez pas.
- Confirmer que deux fichiers de config présentés comme identiques le sont vraiment. Collez le contenu de chaque fichier à tour de rôle, comparez le SHA-256. Deux hachages qui correspondent prouvent l’égalité octet pour octet sans avoir à diffuser des milliers de lignes.
- Générer un identifiant stable pour une charge utile de webhook ou une clé de notification, de sorte que les retransmissions avec le même corps s’effondrent en une seule entrée plutôt que de se déclencher à répétition. Le SHA-256 de la charge utile est le choix conventionnel.
- Produire une clé de cache pour une table de correspondance interne où l’entrée est volumineuse mais où vous n’avez besoin que d’un identifiant court à longueur fixe — par exemple, hacher une requête SQL normalisée pour la réutiliser comme clé de recherche.
- Vérifier si une config ou un identifiant a changé pendant un déploiement. Hachez la valeur avant le changement, puis après. Si les hachages correspondent, le changement n’a pas atterri ; s’ils diffèrent, le changement a atterri — même quand la nouvelle valeur est censée être identique en surface, comme un PEM ré-encodé qui a gagné un saut de ligne final.
Quoi faire du résultat
Un hachage qui correspond à une référence connue, c’est la réponse que vous vouliez — les deux entrées sont identiques octet pour octet, fin de la discussion.
Un écart de hachage est plus intéressant qu’il en a l’air. Avant de présumer que le fichier est mauvais, vérifiez les trois sources courantes de faux positifs : sauts de ligne finaux (collez le même contenu deux fois dans l’outil avec et sans saut de ligne final, et vous obtenez deux hachages différents) ; fins de lignes (\n vs \r\n changent chaque ligne et donc chaque hachage) ; et encodage de caractères (UTF-8 vs UTF-16 vs Windows-1252). Pour les fichiers de config texte, normaliser les fins de lignes à \n et retirer ou ajouter un saut de ligne final résout souvent l’écart immédiatement.
Si les quatre hachages diffèrent entre deux entrées que vous croyiez identiques, les entrées sont réellement différentes — il n’y a pas d’explication au niveau de l’algorithme pour « le SHA-256 diffère mais le MD5 correspond ». Un écart sur un algorithme et une correspondance sur un autre veut dire que vous avez comparé deux choses différentes dans les deux cas, pas qu’un algorithme « est en désaccord » avec un autre.
Pour l’intégrité non adverse (corruption de téléchargement, dérive accidentelle), MD5 reste correct — une collision fortuite sur un fichier non malveillant de 1 Go reste astronomiquement improbable. Pour tout ce qu’un attaquant pourrait exploiter, seuls SHA-256 ou SHA-512 ont leur place dans la conversation. Si un éditeur ne publie encore que du MD5 à côté d’un téléchargement sensible, c’est en soi une observation à signaler.
Stack Harbor utilise la vérification par hachage comme étape standard lors de la copie d’images, de sauvegardes et de paquets de certificats entre les environnements menée dans le cadre des environnements infogérés.