Chiffrement, hachage et HMAC utilisent tous des fonctions cryptographiques, mais répondent à des besoins différents. La première question est : que faut-il protéger ou vérifier ?
- utilisez le chiffrement lorsqu’une information doit rester secrète puis être récupérée ;
- utilisez le hachage pour produire une empreinte reproductible ;
- utilisez HMAC pour authentifier un message avec un secret partagé ;
- utilisez une fonction de dérivation comme PBKDF2 pour dériver une valeur à partir d’un mot de passe.
Le chiffrement protège la confidentialité
Le chiffrement transforme une donnée lisible en texte chiffré à l’aide d’une clé. Avec la bonne clé et les bons paramètres, l’opération est réversible.
AES est un algorithme de chiffrement symétrique. L’outil AES permet d’explorer ce modèle.
Le chiffrement convient lorsqu’il faut retrouver la donnée d’origine. Un hash ne remplace pas ce besoin puisqu’il n’est pas conçu pour être déchiffré.
Le hachage crée une empreinte
Une fonction de hash transforme une entrée en empreinte de taille fixe. La même entrée avec le même algorithme produit le même résultat.
Le générateur de hash et l’outil de comparaison couvrent ces usages.
Un hash seul ne prouve pas qu’une empreinte a été produite par une partie autorisée : quelqu’un qui peut remplacer la donnée et l’empreinte peut recalculer les deux.
HMAC combine hash et secret
HMAC utilise une fonction de hachage avec une clé secrète. Les parties qui partagent ce secret peuvent calculer et vérifier un code d’authentification.
Le générateur/vérificateur HMAC illustre cette différence.
HMAC ne masque pas le message. Il répond à un besoin d’intégrité et d’authenticité, pas de confidentialité.
PBKDF2 va plus loin qu’un hash simple de mot de passe
Les fonctions de hash généralistes sont rapides, ce qui facilite les essais massifs de mots de passe.
PBKDF2 applique de façon répétée une fonction pseudorandom avec un sel et un nombre d’itérations. L’outil PBKDF2 montre le rôle du mot de passe, du sel, des itérations et de la longueur de sortie.
Le sel n’est pas un mot de passe supplémentaire : il peut être stocké avec la valeur dérivée.
Quel mécanisme choisir ?
| Besoin |
Mécanisme adapté |
Réversible ? |
Secret nécessaire ? |
| Masquer une donnée puis la récupérer |
AES |
Oui |
Oui |
| Produire une empreinte |
Hash |
Non |
Non |
| Authentifier un message avec un secret partagé |
HMAC |
Non |
Oui |
| Dériver une valeur d’un mot de passe |
PBKDF2 |
Non |
Mot de passe |
Ces mécanismes peuvent coexister dans une même application.
Erreurs fréquentes
Encoder n’est pas chiffrer. Base64 ne fournit aucune confidentialité.
Hasher n’est pas chiffrer. Une empreinte n’est pas un texte chiffré.
HMAC ne masque pas un message. Il l’authentifie avec un secret.
Les mots de passe ne devraient généralement pas être stockés comme des données déchiffrables.
Pour le contexte plus large, consultez Sécurité Web : protections essentielles.
Exemple concret : choisir entre AES, hash, HMAC et PBKDF2
Prenons une application qui reçoit des fichiers confidentiels, authentifie ses utilisateurs et échange des requêtes avec un service partenaire. Elle peut avoir besoin des quatre mécanismes, mais à des endroits différents.
Le fichier confidentiel doit pouvoir être relu : il relève donc du chiffrement. Un hash peut être calculé en parallèle pour vérifier qu’un fichier reçu plus tard est identique, mais cette empreinte ne protège pas son contenu. Les requêtes envoyées au partenaire peuvent être accompagnées d’un HMAC afin que le destinataire vérifie qu’elles ont été calculées avec le secret partagé. Enfin, le mot de passe d’un utilisateur ne doit pas être stocké comme un texte que l’application déchiffre : une fonction de dérivation prévue pour les mots de passe répond à un autre besoin.
Cet exemple montre pourquoi le choix ne se fait pas entre quatre « concurrents ». Ces primitives occupent des rôles complémentaires.
Ce qu’il faut conserver avec une donnée chiffrée
Un résultat AES n’est pas toujours exploitable avec la seule clé. Selon le mode utilisé, il faut également conserver les paramètres nécessaires au déchiffrement, par exemple un vecteur d’initialisation ou un nonce. Ces valeurs n’ont pas forcément à être secrètes, mais elles doivent être associées correctement au message.
La clé, en revanche, doit être protégée. Copier une clé secrète dans le même fichier public que les données chiffrées annule une grande partie de l’intérêt du chiffrement.
Pour vérifier qu’un fichier téléchargé correspond exactement à une référence publiée, un hash peut suffire si l’empreinte de référence provient d’une source digne de confiance. Si un système doit vérifier qu’un message a été produit par un partenaire connaissant un secret, HMAC apporte cette dimension supplémentaire.
La provenance de la valeur de référence est donc aussi importante que l’algorithme utilisé.
Checklist avant de choisir
Posez quatre questions : la valeur doit-elle rester secrète ? doit-elle être récupérable ? faut-il authentifier l’émetteur ? s’agit-il d’un mot de passe ? Les réponses orientent rapidement vers le mécanisme approprié.
Il faut ensuite regarder les paramètres : algorithme, taille de clé, sel, nombre d’itérations, nonce ou format de sortie. Un bon algorithme avec des paramètres mal gérés peut produire une implémentation fragile.
Enfin, un outil pédagogique permet de comprendre les entrées et sorties, mais la sécurité d’une application réelle dépend aussi de la gestion des clés, de leur rotation, des bibliothèques utilisées et de l’ensemble de l’architecture.