Hachage, chiffrement et encodage : quelles différences ?

Niveau : débutant.

Prérequis : savoir créer un fichier texte, ouvrir un terminal et exécuter un script Python local. Aucune connaissance préalable en cryptographie n’est nécessaire. Python 3 suffit pour l’exercice ; aucune dépendance externe ni donnée réelle n’est utilisée.

Travaille uniquement avec la chaîne fictive fournie. L’objectif est d’observer des transformations, pas de concevoir un système cryptographique, de manipuler un mot de passe réel ou de choisir seul un algorithme pour une application en production.

Avant de regarder un format ou un nom d’algorithme, demande quel problème doit être résolu. L’encodage répond à une question de représentation : comment exprimer des octets avec un alphabet accepté par un protocole, un fichier ou une interface ? Le chiffrement répond à une question de confidentialité : comment rendre une information inintelligible sans la clé autorisée ? Le hachage répond à une question d’empreinte : comment produire un résumé déterministe utile pour comparer des données sans prévoir de reconstruire l’entrée depuis ce résumé ?

Ces opérations peuvent se succéder sans devenir équivalentes. Une application peut chiffrer un document, puis encoder le résultat en base64 pour un champ textuel. Elle peut aussi calculer une empreinte du fichier pour détecter une différence. Un texte base64 transformé n’est pas secret et une empreinte hexadécimale n’est pas un message chiffré attendant une clé.

La bonne classification dépend du but et des propriétés attendues, pas de l’apparence du résultat. Cette distinction évite de promettre de la confidentialité avec un format public ou de traiter une empreinte comme une preuve absolue d’authenticité.

Dimension	Encodage	Chiffrement	Hachage
But principal	Représenter ou transporter	Protéger la confidentialité	Produire une empreinte
Réversibilité	Oui, par décodage public	Oui, avec la clé et les paramètres requis	Aucune opération inverse prévue
Secret requis	Non	Oui pour la confidentialité	Non pour un hash simple
Taille du résultat	Dépend du format et de l’entrée	Proche de l’entrée avec des métadonnées	Fixe pour une fonction donnée
Modification de l’entrée	Modifie la représentation	Modifie le texte chiffré	Modifie généralement fortement l’empreinte

Une clé est une valeur utilisée par une opération cryptographique. Selon le système, la même clé ou une paire de clés intervient pour chiffrer et déchiffrer. Sa protection, sa génération, son stockage, sa rotation et les paramètres associés font partie du mécanisme ; masquer le nom de l’algorithme n’apporte pas cette sécurité.

Un sel est différent d’une clé. C’est une valeur unique associée à une entrée, normalement stockée avec le résultat, qui empêche deux entrées identiques de produire automatiquement le même résultat dans un mécanisme de stockage de mots de passe. Le sel n’a pas besoin d’être secret. Il ne chiffre rien et ne transforme pas une fonction rapide généraliste en mécanisme adapté aux mots de passe.

Base64 associe des groupes de bits à un alphabet textuel. La RFC 4648 normalise notamment les alphabets base16, base32 et base64 ainsi que leur remplissage. Une personne qui possède la chaîne et connaît le format peut la décoder sans clé. Base64 n’est donc pas du chiffrement. Il ne fournit ni confidentialité, ni authenticité, ni contrôle d’accès.

L’encodage reste utile. Un système prévu pour du texte peut transporter une image, une clé publique ou un bloc binaire sous une forme compatible. L’hexadécimal rend une empreinte facile à copier et l’URL encoding adapte certains caractères à une URL. Ces formats répondent à des contraintes techniques, pas à un besoin de secret.

Décoder une chaîne donne des octets, mais leur interprétation dépend encore du type, du jeu de caractères et du protocole. Base64 peut contenir du texte, une image, des données compressées ou un résultat chiffré. Le contenu obtenu peut rester dangereux si une application l’exécute sans contrôle.

Le chiffrement combine une donnée, une clé et des paramètres pour produire un texte chiffré. Le déchiffrement autorisé retrouve la donnée. Cette réversibilité contrôlée le distingue du hachage. La confidentialité dépend toutefois de l’ensemble du système : qualité des clés, génération aléatoire, paramètres, stockage, contrôle d’accès et construction normalisée. Une recette maison peut échouer même si chaque brique porte un nom cryptographique.

Le chiffrement seul ne garantit pas forcément l’intégrité ou l’authenticité. Un mécanisme de chiffrement authentifié est conçu pour détecter une modification et associer éventuellement des données de contexte non chiffrées. Le NIST SP 800-38D décrit GCM et GMAC comme des modes assurant des propriétés d’authentification, avec ou sans chiffrement selon l’usage. Cette référence illustre la séparation des objectifs ; elle ne constitue pas une recette à recopier sans bibliothèque maintenue.

Pour une application réelle, pars d’un besoin et d’un modèle de menace, puis utilise une bibliothèque de haut niveau maintenue selon les recommandations officielles de la plateforme. Ne conçois pas de combinaison d’algorithmes à partir d’exemples pédagogiques.

Une fonction de hachage reçoit une entrée de longueur variable et produit une empreinte de taille fixe. Elle est déterministe : la même suite d’octets donne la même empreinte. Une petite modification de l’entrée produit en général un résultat très différent. La norme FIPS 180-4 du NIST spécifie la famille Secure Hash Standard, dont SHA-256, utilisée dans l’exercice uniquement pour observer ce comportement.

Le hachage peut contribuer à un contrôle d’intégrité : si une empreinte calculée après transfert diffère d’une valeur fiable obtenue séparément, le contenu n’est pas identique. Une égalité indique que les octets comparés ont produit la même empreinte, mais elle ne prouve pas à elle seule qui a publié le fichier. Si un adversaire peut remplacer à la fois le fichier et l’empreinte affichée au même endroit, la comparaison ne fournit pas d’authenticité. Une signature ou un mécanisme authentifié répond à un besoin différent.

Dire qu’un hash est « irréversible » ne signifie pas que l’entrée devient impossible à retrouver par toute méthode. Pour une entrée prévisible, une personne peut tester des candidats, calculer leurs empreintes et repérer une égalité. Le résultat ne cache donc pas automatiquement un numéro court, un code commun ou un mot de passe. Les collisions existent aussi en théorie parce qu’un espace d’entrées illimité est résumé dans un espace de sortie fini ; la résistance attendue dépend de la fonction et de l’usage.

Ne stocke pas un mot de passe avec un simple SHA-256, même accompagné d’un sel. Une fonction généraliste rapide facilite aussi les essais massifs de candidats. Un mécanisme dédié au stockage des mots de passe ajoute un sel propre à chaque secret et un coût de calcul configurable afin de ralentir la vérification. Il doit être implémenté par une bibliothèque reconnue et configuré selon les recommandations actuelles de l’autorité ou de la plateforme concernée.

Le NIST SP 800-63B demande aux vérificateurs de stocker les mots de passe sous une forme résistante aux attaques hors ligne, salée et hachée avec un mécanisme adapté et un facteur de coût. Le texte décrit aussi l’intérêt éventuel d’une étape supplémentaire avec une clé secrète conservée séparément. Cette exigence ne transforme pas un tutoriel court en architecture prête pour la production.

Le sel empêche surtout que deux comptes ayant le même mot de passe partagent automatiquement la même valeur stockée et réduit l’efficacité de tables précalculées communes. Il peut être enregistré près du résultat. Une clé secrète supplémentaire, parfois appelée poivre, répond à un autre modèle de menace et impose sa propre gestion. N’invente pas ce dispositif dans le code applicatif. Utilise le mécanisme fourni et maintenu par le cadre d’authentification, puis suis ses procédures de migration et de mise à niveau du coût.

Cet exercice compare une représentation réversible et une empreinte. Il ne chiffre rien et n’utilise aucun mot de passe. Crée transformations.py avec ce code basé uniquement sur la bibliothèque standard de Python :

import base64
import hashlib

data = b"atelier-fictif-42"

encoded = base64.b64encode(data)
decoded = base64.b64decode(encoded)
digest = hashlib.sha256(data).hexdigest()
changed_digest = hashlib.sha256(data + b"!").hexdigest()

print(encoded.decode("ascii"))
print(decoded == data)
print(digest)
print(changed_digest)
print(digest == changed_digest)

Exécute python3 transformations.py. La première ligne doit être YXRlbGllci1maWN0aWYtNDI= et la deuxième True, ce qui démontre que base64 se décode sans secret. La troisième doit être 3ef74a0924e0f8c6d4cd4755d45ee7de50d8a270b06e5dbf85964096be6d890a. La quatrième diffère après l’ajout d’un seul octet et la dernière vaut False.

Critère observable

L’exercice est réussi si tu récupères exactement les octets d’origine par décodage, obtiens une empreinte SHA-256 de 64 caractères hexadécimaux et constates qu’une entrée modifiée donne une autre empreinte. Note ensuite trois conclusions : base64 est réversible sans clé ; SHA-256 ne propose pas de décodage ; une empreinte différente détecte ici une modification. Ajoute deux limites : cette démonstration ne fournit ni chiffrement, ni solution de stockage de mots de passe.

• Appeler base64 du chiffrement. Toute personne peut appliquer le décodage public.
• Parler de déchiffrer un hash. Une fonction de hachage n’a pas d’opération inverse prévue ; les essais de candidats sont un autre processus.
• Hasher un mot de passe avec une fonction rapide. Utilise un mécanisme dédié conforme aux recommandations officielles.
• Confondre sel et clé. Le sel est normalement public et unique ; il ne donne pas de confidentialité.
• Prendre une empreinte pour une preuve d’origine. Vérifie comment la valeur de référence est authentifiée.
• Croire que le chiffrement garantit toute l’intégrité. Choisis une construction de haut niveau qui couvre explicitement les propriétés nécessaires.
• Inventer une combinaison cryptographique. Une concaténation, un encodage ou plusieurs passages ne remplacent pas un protocole analysé.
• Réutiliser un exemple pédagogique en production. L’exercice montre deux transformations isolées, sans gestion de clés, authentification, format de message ni traitement des erreurs hostiles.

Le vocabulaire précis aide à poser le bon diagnostic : représentation pour l’encodage, confidentialité pour le chiffrement, empreinte et comparaison pour le hachage. Dans un système réel, ces objectifs se combinent avec l’authentification, l’autorisation, la gestion des clés, la protection des métadonnées et la mise à jour des bibliothèques. Aucun mécanisme isolé ne remplace cette architecture.