L’encodage, le hachage et le chiffrement transforment les données, mais ne promettent pas le même résultat. L’encodage change la représentation. Le hachage crée un condensat de taille fixe. Le chiffrement protège un contenu lisible avec une clé.
Réponse rapide : utilisez l’encodage lorsqu’un système exige une représentation compatible. Utilisez un hachage pour une empreinte répétable ou un contrôle d’intégrité. Utilisez un chiffrement authentifié lorsque des systèmes autorisés doivent récupérer des données confidentielles. Base64 est un encodage, pas un chiffrement.
Cette page compare la finalité, la réversibilité, les clés, les algorithmes, les erreurs et les exemples. Elle relie ces choix aux outils d’encodage, aux outils de hachage et aux outils de chiffrement.
Quelle est la différence principale ?
La différence principale est la promesse. L’encodage promet une représentation normalisée. Le hachage promet un condensat déterministe dont les propriétés dépendent de l’algorithme. Le chiffrement promet la confidentialité lorsque l’algorithme, le mode, les clés, les nonces, l’authentification et l’implémentation sont adaptés.
| Opération | Finalité principale | Réversible | Clé secrète nécessaire | Sortie habituelle | Exemples |
|---|---|---|---|---|---|
| Encodage | Représenter des données pour le transport ou le stockage | Oui | Non | Texte ou octets avec une autre syntaxe | Base64, hexadécimal, encodage en pourcentage |
| Hachage | Créer une empreinte pour l’intégrité ou la comparaison | Pas d’inversion pratique | Non | Condensat de taille fixe | SHA-256, SHA-384, SHA-512 |
| Chiffrement | Empêcher une lecture non autorisée | Oui, avec la bonne clé | Oui | Texte chiffré, nonce et étiquette | AES-GCM, ChaCha20-Poly1305 |
L’apparence ne définit pas l’opération. Base64 peut sembler aléatoire, mais toute personne peut le décoder. Un hachage hexadécimal peut ressembler à du texte chiffré, mais ne restaure pas la source. Un texte chiffré peut être encodé en Base64 pour le transport.
Qu’est-ce que l’encodage ?
L’encodage associe une représentation à une autre selon des règles publiques. Il apporte une compatibilité entre systèmes et n’exige pas de secret. Un décodeur peut inverser une entrée valide lorsqu’il connaît le schéma.
Base64 encode souvent du binaire en texte. RFC 4648 définit Base16, Base32 et Base64, leurs alphabets, leur remplissage et leur comportement canonique. Base64 transporte des octets dans des systèmes orientés texte. Il ne masque pas ces octets.
Un encodeur Base64 regroupe des bits et les mappe vers un alphabet limité. Le remplissage complète le dernier groupe. Les variantes peuvent utiliser des alphabets différents. Base64 compatible URL remplace des caractères problématiques. Le récepteur doit connaître la variante et la règle de remplissage.
L’encodage hexadécimal représente chaque octet avec deux caractères de base 16. Il est facile à inspecter et à copier, mais double la longueur avant les enveloppes supplémentaires. Base64 est généralement plus court que l’hexadécimal, tout en restant plus grand que le binaire.
L’encodage en pourcentage représente des octets dans des composants URL. Les entités HTML représentent des caractères spéciaux dans le balisage. Les encodages de caractères, comme UTF-8, associent des caractères à des octets. Ces opérations résolvent la compatibilité, pas la confidentialité.
Vous pouvez tester une entrée contrôlée avec l’encodeur et décodeur Base64. Ne collez pas de mots de passe, clés ou données réglementées sans confirmer le modèle de traitement. Le navigateur réduit certains chemins de transmission, mais ne remplace pas la sécurité de l’appareil.
Base64 est-il un chiffrement ?
Non. Base64 utilise une correspondance publique et réversible sans clé secrète. Toute personne qui reçoit le texte peut le décoder. Base64 peut envelopper un texte chiffré, mais ne fournit pas la confidentialité par lui-même.
Cette différence compte pour les configurations, cookies, jetons et journaux. Un secret encodé reste un secret à protéger. Utiliser Base64 comme barrière peut exposer des identifiants et des données personnelles.
Qu’est-ce qu’un hachage ?
Une fonction de hachage cryptographique accepte une entrée de longueur variable et renvoie un condensat fixe. La même entrée produit le même condensat. Un petit changement doit modifier fortement le résultat. La sécurité demande aussi une résistance à la préimage, à la seconde préimage et aux collisions délibérées.
NIST FIPS 180-4 spécifie Secure Hash Standard. Il inclut SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256. « SHA-2 » désigne une famille, pas une taille unique.
Réponse directe : utilisez un hachage lorsque vous voulez un condensat répétable sans récupérer l’entrée. Utilisez le chiffrement lorsqu’une partie autorisée doit la récupérer.
Les éditeurs publient souvent un condensat avec un téléchargement. Calculez le même hachage sur les octets téléchargés et comparez-le. Une correspondance prouve l’égalité avec les octets utilisés pour le condensat publié. Elle ne prouve pas qui l’a publié. Il faut un canal authentique ou une signature.
La calculatrice SHA-2 calcule des résultats courants. All Hashes Generator (page en anglais) montre plusieurs algorithmes. Plusieurs sorties ne rendent pas un algorithme faible plus sûr. Choisissez selon l’exigence et la norme.
Les hachages ne sont pas des identifiants uniques
Un condensat fixe représente un ensemble illimité d’entrées. Des collisions existent donc. Un hachage sûr rend les collisions utiles difficiles, mais ne les rend pas impossibles.
N’utilisez pas un condensat comme preuve universelle d’identité. Évaluez l’algorithme, la construction de l’entrée, l’attaquant et les conséquences. Les anciens hachages peuvent détecter une corruption accidentelle, mais échouer face à un attaquant.
Hash Analyzer (page en anglais) peut suggérer des algorithmes selon la longueur et la syntaxe. Il ne prouve pas l’algorithme qui a créé la valeur. Le contexte reste nécessaire.
Le hachage de mots de passe exige un modèle spécifique
Un hachage général est rapide par conception. Cela aide à vérifier des fichiers, mais permet de tester rapidement de nombreux mots de passe.
Le stockage de mots de passe exige une fonction dédiée ou une dérivation de clé. Elle doit utiliser un sel unique et un coût délibéré. Elle exige aussi des paramètres contrôlés, une comparaison sûre, une migration et la protection des copies. NIST SP 800-63B donne des conseils actuels.
Un sel n’a pas besoin d’être secret. Il empêche qu’un même mot de passe produise le même vérificateur dans plusieurs comptes. Un pepper est un autre secret avec des exigences opérationnelles différentes. Aucun des deux ne transforme Base64 en chiffrement.
Une somme de contrôle n’est pas toujours un hachage cryptographique
Les sommes détectent des changements accidentels. CRC convient aux erreurs de transmission et de stockage. Il ne résiste généralement pas à une modification délibérée. Les hachages cryptographiques visent des propriétés plus fortes.
Définissez l’exigence avant de choisir. Utilisez une somme contre les erreurs accidentelles. Utilisez un hachage cryptographique ou un MAC lorsqu’un attaquant peut modifier les données. Utilisez une signature numérique lorsque le récepteur doit vérifier l’origine avec une clé publique.
Qu’est-ce que le chiffrement ?
Le chiffrement transforme un texte clair en texte chiffré avec une clé. Le déchiffrement restaure l’original. Un système sûr exige aussi la génération, le mode, les nonces, l’authentification, le stockage, la rotation et les contrôles d’accès corrects.
NIST FIPS 197 spécifie AES. AES utilise des blocs de 128 bits et des clés de 128, 192 ou 256 bits. AES ne définit pas à lui seul le traitement d’un message long. Un mode de fonctionnement fournit cette construction.
Les modes authentifiés protègent la confidentialité et détectent les modifications. AES-GCM est un exemple courant. Son étiquette permet de refuser un texte chiffré ou des données associées modifiés. Chiffrer sans authentifier peut divulguer des informations ou accepter des modifications contrôlées.
NIST SP 800-38D définit GCM et GMAC. Ses règles de nonce sont essentielles. Réutiliser un nonce avec la même clé GCM peut détruire la sécurité. Une interface ne peut pas empêcher ce problème si le système ne gère pas l’état entre les sessions.
Vous pouvez utiliser AES Encryption (page en anglais) pour apprendre et effectuer des transformations contrôlées. Un outil du navigateur ne constitue pas un système de clés complet. La production exige un protocole révisé et un cycle protégé.
Chiffrement symétrique et asymétrique
Le chiffrement symétrique utilise une clé secrète partagée. La même clé, ou des clés liées, chiffre et déchiffre. AES est symétrique. Il est efficace, mais les parties doivent partager et conserver la clé en sécurité.
Le chiffrement asymétrique utilise une paire publique et privée. Dans les schémas adaptés, la clé publique chiffre pour le détenteur de la clé privée. La cryptographie publique permet aussi les signatures, mais signer n’est pas chiffrer.
De nombreux protocoles combinent les deux. Les méthodes publiques établissent ou protègent une clé symétrique temporaire. Le chiffrement authentifié protège les données. Le protocole authentifie aussi les participants, lie le contexte et évite les rejeux.
La collection de clés, certificats et jetons fournit des outils associés. Un certificat lie une identité à une clé publique par une chaîne de signatures. Un JWT peut être signé ou chiffré. Ses segments Base64url ne le rendent pas secret.
Chiffrement au repos et en transit
Le chiffrement au repos protège les données selon un modèle de menace. Le chiffrement de disque aide lorsqu’un appareil éteint est perdu. Le chiffrement de champs limite certains chemins. Les sauvegardes, journaux, exports, index et caches exigent une revue distincte.
Le chiffrement en transit protège la communication entre extrémités. TLS est l’exemple Web courant. Il ne protège pas les données après leur déchiffrement par une extrémité légitime. Les extensions, appareils compromis, journaux et utilisateurs autorisés peuvent encore voir le texte clair.
« Chiffré » est une affirmation incomplète sans portée. Demandez quelles données sont protégées, où le chiffrement commence et finit, qui contrôle les clés et quels attaquants sont inclus.
Où placer les codes d’authentification de message ?
Un code d’authentification de message, ou MAC, utilise un secret partagé pour protéger l’intégrité et l’authenticité entre les parties. HMAC combine un hachage cryptographique avec une construction précise. Ce n’est pas un simple hachage et il ne chiffre pas le contenu.
NIST FIPS 198-1 spécifie HMAC. Un récepteur qui possède la clé peut vérifier le message et l’étiquette. L’étiquette ne permet pas de récupérer le message. Toute personne qui vérifie avec la clé partagée peut aussi produire des étiquettes valides.
Utilisez un MAC lorsque le message peut rester visible, mais que vous devez détecter les changements entre participants. Utilisez un chiffrement authentifié si vous devez aussi assurer la confidentialité. Utilisez une signature si la vérification doit fonctionner avec une clé publique.
Où placer les signatures numériques ?
Une signature numérique utilise une clé privée pour signer et une clé publique pour vérifier. Elle vise l’authenticité et l’intégrité. Dans certains systèmes, elle soutient aussi le non-repudiation. Elle ne masque pas le contenu signé.
Les signatures portent souvent sur une représentation structurée ou un condensat. La canonisation compte, car deux séquences peuvent représenter des données similaires. Les protocoles doivent aussi lier les algorithmes, le contexte, les identifiants et les expirations.
NIST SP 800-175B explique les normes cryptographiques fédérales. Utilisez des bibliothèques maintenues et des protocoles établis. N’assemblez pas des primitives à partir de sorties isolées.
Comment ces opérations peuvent-elles travailler ensemble ?
Une application sûre utilise souvent plusieurs transformations dans un ordre défini. Considérez un message chiffré transporté en JSON :
- L’application sérialise le texte clair en une séquence exacte d’octets.
- Un algorithme authentifié crée le texte chiffré et une étiquette avec une clé et un nonce.
- Base64url encode les champs binaires pour le transport JSON.
- Le récepteur décode Base64url, puis effectue le déchiffrement authentifié.
- Le récepteur refuse le message si l’authentification échoue.
La couche d’encodage fournit la représentation. La couche de chiffrement fournit la confidentialité et l’intégrité. Inverser seulement l’encodage montre le texte chiffré, et non le texte clair. Omettre l’authentification invalide le modèle.
Un autre flux peut hacher un fichier public, signer le condensat, puis encoder la signature en Base64. Le hachage crée une entrée fixe. La signature la lie à une clé privée. Base64 transporte la signature comme texte. Chaque étape a une promesse différente.
Guide de décision
Commencez par le résultat nécessaire, et non par l’apparence de la sortie.
| Exigence | Méthode | Condition importante |
|---|---|---|
| Placer des octets binaires dans un champ texte | Encodage | Les deux systèmes conviennent de la variante |
| Comparer un fichier avec un condensat fiable | Hachage cryptographique | Obtenir le condensat d’une source fiable |
| Détecter les changements entre parties partageant un secret | MAC | Protéger et renouveler la clé partagée |
| Masquer le contenu et détecter les changements | Chiffrement authentifié | Respecter les règles de clés et de nonces |
| Stocker des vérificateurs de mots de passe | Hachage de mot de passe ou KDF | Utiliser des sels uniques et des coûts adaptés |
| Permettre une vérification publique de l’éditeur | Signature numérique | Protéger la clé privée et valider l’identité |
| Détecter les erreurs accidentelles | Somme de contrôle | Ne pas revendiquer une résistance aux attaquants |
Si un système autorisé doit récupérer l’entrée, un hachage unidirectionnel est incorrect. Si la confidentialité n’est pas nécessaire, le chiffrement peut ajouter des risques de clés. Si seule la compatibilité compte, utilisez un encodage documenté et des contrôles de sécurité séparés.
Erreurs habituelles
Erreur 1 : prendre un texte illisible pour un texte sûr
Une sortie étrange ne prouve rien. Base64, l’hexadécimal, les données compressées, les hachages et le texte chiffré peuvent sembler inhabituels. Identifiez l’opération et ses propriétés.
Erreur 2 : chiffrer sans authentification
La confidentialité ne prouve pas que le texte chiffré reste intact. Préférez une construction authentifiée établie. Validez l’étiquette avant d’utiliser le texte clair.
Erreur 3 : réutiliser les nonces ou vecteurs d’initialisation
Les exigences dépendent de l’algorithme et du mode. Certains demandent l’unicité, d’autres l’imprévisibilité. Une réutilisation incorrecte peut révéler des relations ou affaiblir les clés d’authentification.
Erreur 4 : stocker les clés avec le texte chiffré
Une clé conservée avec les données peut supprimer la limite de menace. Utilisez un système de secrets adapté. Limitez l’accès, journalisez les opérations, renouvelez les clés et préparez la récupération.
Erreur 5 : appliquer un hachage rapide à des secrets peu entropiques
Un attaquant peut tester des valeurs courtes ou courantes hors ligne. Utilisez une construction dédiée aux mots de passe et suivez les conseils actuels de la plateforme.
Erreur 6 : faire confiance à un condensat du même emplacement compromis
Un attaquant qui remplace un fichier peut aussi remplacer son condensat voisin. Utilisez un manifeste signé, un canal fiable ou une source authentifiée indépendante.
Erreur 7 : concevoir un nouveau protocole cryptographique
Des primitives sûres peuvent échouer dans une composition fragile. Préférez des normes révisées, des bibliothèques matures et une revue experte pour les systèmes importants.
Processus sûr avec des outils du navigateur
- Décidez si vous avez besoin d’une représentation, d’une intégrité, d’une authentification ou d’une confidentialité.
- Retirez les secrets de production et les données personnelles des exemples.
- Sélectionnez un outil spécifique pour l’opération.
- Confirmez l’algorithme, l’alphabet, le mode, le remplissage et l’encodage de sortie.
- Testez un exemple connu avant de faire confiance à une valeur inconnue.
- Conservez l’original jusqu’à une vérification indépendante.
- Utilisez une bibliothèque maintenue dans le code de production.
Questions fréquentes
Un hachage peut-il remplacer le chiffrement ?
Non. Un hachage ne permet pas de récupérer la donnée. Utilisez un chiffrement authentifié lorsqu’un destinataire autorisé doit la récupérer.
Le chiffrement peut-il remplacer un hachage ?
Non. Le chiffrement n’est pas un mécanisme général de comparaison. Utilisez une construction authentifiée ou un hachage selon l’exigence.
SHA-256 est-il un chiffrement ?
Non. SHA-256 est une fonction de hachage de la famille SHA-2.
AES est-il un hachage ?
Non. AES est un chiffrement par blocs symétrique. Son usage exige un mode et une gestion de nonce adaptés.
Base64 réduit-il la taille des données ?
Non. Base64 augmente généralement la taille des octets. Il fournit une représentation texte, pas une compression.
Quelle méthode doit protéger un jeton API ?
Conservez le jeton dans un gestionnaire de secrets et utilisez TLS pour le transport. N’utilisez pas Base64 comme protection.
Quel algorithme de chiffrement est le plus sûr ?
Il n’existe pas un choix sans contexte. Utilisez une construction authentifiée et une bibliothèque maintenue selon le protocole et le modèle de menace.
Règle finale de sélection
L’encodage résout la représentation. Le hachage résout un condensat et certaines comparaisons. Le MAC résout une authentification partagée. La signature résout une vérification publique. Le chiffrement authentifié résout la confidentialité avec intégrité.
Choisissez d’abord la propriété nécessaire. Documentez les clés, algorithmes, formats, nonces, règles d’erreur et limites. Une sortie qui semble secrète ne constitue jamais une preuve de sécurité.