Comprendre SHA-256 : des octets au condensat

La réponse courte

SHA-256 calcule un condensat de 256 bits, soit 64 caractères hexadécimaux. Des octets identiques produisent le même condensat. La comparaison aide donc à comparer un fichier à une référence connue. À elle seule, elle n’indique ni qui a créé le fichier ni si son contenu est correct ou sans danger.

Ce texte développe une partie de mon support « Wie Computer funktionieren ». Ce qui m’intéresse est le lien pratique : utiliser une somme de contrôle pour des téléchargements, sauvegardes ou journaux exige de savoir quelle question elle résout.

Pourquoi 256 bits donnent exactement 64 caractères hexadécimaux

Un bit a deux valeurs possibles. Quatre bits offrent 16 motifs, correspondant aux chiffres hexadécimaux de 0 à F. Un chiffre représente donc quatre bits. Pour SHA-256 :

256 Bits / 8 = 32 Bytes
256 Bits / 4 = 64 Hexzeichen

La chaîne représente le résultat, pas le fichier initial compressé. Même un très gros fichier produit la même longueur. On ne peut donc pas, en général, reconstruire le fichier à partir de cette courte valeur.

Un calcul concret : un octet contient huit bits, donc 256 motifs possibles. Deux chiffres hexadécimaux les représentent, de 00 à FF. Un condensat de 32 octets exige donc 32 paires. La casse ne change pas les valeurs numériques représentées.

Le texte visible n’est pas encore l’entrée

Pour un texte, il faut préciser les octets hachés. L’encodage transforme les caractères en octets ; les fins de ligne appartiennent aussi au fichier. Les trois caractères ASCII abc correspondent en UTF-8 aux octets 61 62 63.

abc ohne Zeilenende: 61 62 63
abc mit LF:         61 62 63 0A
abc mit CRLF:       61 62 63 0D 0A

Ce sont trois entrées différentes. Si deux outils renvoient des valeurs différentes, je vérifierais d’abord les octets : fin de ligne ajoutée, autre encodage, marque d’ordre des octets ? Un texte visuellement identique peut être encodé différemment.

Pour les trois octets 61 62 63 la valeur SHA-256 est :

ba7816bf8f01cfea414140de5dae2223
b00361a396177a9cb410ff61f20015ad

Les deux lignes forment une seule valeur ; la coupure facilite seulement la lecture. Vous pouvez la calculer plus bas dans le navigateur. L’exercice détaillé figure dans Vérifier des fichiers avec PowerShell.

Ce qui se passe dans l’algorithme

Le Secure Hash Standard du NIST décrit le traitement exact. En simplifiant, SHA-256 ajoute un remplissage et la longueur initiale du message, puis le divise en blocs de 512 bits. Chaque bloc traverse 64 tours utilisant des mots de 32 bits, des opérations binaires et des additions modulo 2 puissance 32. L’état obtenu fournit finalement la sortie de 256 bits.

Ces tailles répondent à des questions différentes : 512 bits pour un bloc, 32 pour les mots, 256 pour le résultat. Le nombre 64 apparaît pour les tours et la représentation hexadécimale, avec deux sens différents.

Il s’agit d’une explication du processus. Pour une application, j’utiliserais une bibliothèque reconnue. Une implémentation pédagogique aide à comprendre, mais se distingue d’une implémentation vérifiée en production.

Ce que démontre une comparaison

Supposons que je conserve la somme de contrôle d’un PDF, puis recalcule celle d’un fichier reçu. Une différence indique des octets différents. La cause reste ouverte : un export a pu modifier uniquement les métadonnées, ou le contenu visible a changé.

Sous les hypothèses cryptographiques habituelles, une correspondance indique fortement des octets identiques. Ce n’est pas une preuve mathématique d’unicité pour tous les fichiers : des entrées différentes peuvent partager une sortie. L’exigence pratique est de ne pas pouvoir trouver délibérément ces collisions avec des moyens raisonnables.

L’origine de la référence est décisive. Si un attaquant remplace fichier et somme de contrôle, ils correspondent de nouveau. Une référence indépendante et fiable apporte davantage qu’une valeur quelconque sur le même site inconnu.

Les limites importantes dans un projet

Le hachage ne chiffre pas les données. Hacher un contenu privé ne rend pas son fichier confidentiel, et un condensat seul n’est pas une signature numérique. J’explique la distinction dans Hachage, chiffrement et signature.

Un journal chaîné a également besoin d’un point de référence fiable. Quiconque peut réécrire toute la chaîne et recalculer les condensats peut créer une autre histoire cohérente. Pour belegwerk cette limite est importante pour comprendre le registre. Le hachage ne vérifie pas les sources et n’assume pas la responsabilité de la saisie initiale.

Un passage rapide de SHA-256 ne convient pas au stockage des mots de passe. Il faut des méthodes avec sel et un coût de calcul ou de mémoire volontairement accru. Les recommandations OWASP sur le stockage des mots de passe traitent séparément ce besoin.

Trois questions pour votre usage

1. Quel fichier ou quelle suite d’octets vérifie-t-on exactement ?
2. D’où vient la référence fiable ?
3. Que doit établir la comparaison : octets inchangés, origine ou exactitude du fond ?

Si la troisième question appelle plusieurs réponses, le processus demande généralement plusieurs contrôles. Un bon usage de la cryptographie commence pour moi par cette distinction.