Encodage et chiffrement : quelle différence ?

Quatre transformations que l’on mélange

Encodage : survivre au canal, pas le secret

L’encodage mappe octets ou texte vers un alphabet sûr pour le canal. Le courriel limitait autrefois les lignes à l’ASCII ; JSON et XML sont du texte ; les URL réservent des caractères comme ?, &, = et # à la structure. Les encodages sont des algorithmes publics — connaître le schéma suffit pour les inverser.

Base64

Base64 (RFC 4648) représente des données binaires avec 64 caractères ASCII imprimables plus du remplissage. La taille grossit d’environ un tiers, mais vous pouvez intégrer images, jetons ou ciphertext dans des chaînes JSON. Décoder est trivial avec n’importe quelle bibliothèque ou les outils base64-encoder et base64-decoder de SmartKitio — c’est pourquoi Base64 n’est pas un coffre.

Hello → SGVsbG8=
(JSON-safe string carrying the same bytes)

Encodage URL (pourcent)

Les URL se décomposent en schéma, autorité, chemin, requête et fragment. Les caractères réservés dans les valeurs de requête doivent être encodés en pourcent (%20 pour l’espace, %26 pour &) pour que les analyseurs ne malinterprètent pas la saisie utilisateur. L’url-encoder de SmartKitio applique les mêmes règles que les navigateurs pour construire les query strings — l’encodage concerne la structure, pas cacher des valeurs à l’utilisateur au clavier.

Hexadécimal

L’hex écrit chaque octet en deux nibbles (0-9, a-f). La taille double comme en Base64, mais sans ambiguïté de casse ou d’alphabet. On voit l’hex dans les hash de commits Git, les adresses MAC et les dumps de debug — pas parce que l’hex est sécurisé, mais parce qu’il se lit sans ambiguïté à voix haute.

Chiffrement : confidentialité avec des clés

Le chiffrement utilise une clé et un algorithme pour produire un ciphertext inutilisable sans matériel de clé autorisé. Les schémas symétriques comme AES emploient un secret partagé pour les données en volume ; les schémas asymétriques comme RSA ou ECDH négocient des clés ou signent des messages. Les API modernes préfèrent le chiffrement authentifié (par exemple AES-GCM) pour détecter la falsification, pas seulement du plaintext brouillé.

AES dans les applications

Les développeurs rencontrent AES pour chiffrer des fichiers au repos, des colonnes de base ou des charges de session. Un usage correct exige des IV ou nonces aléatoires, une rotation des clés, et surtout ne pas inventer son propre mode. Une clé AES statique dans une app mobile reste un secret embarqué côté client — les attaquants peuvent l’extraire.

TLS sur le fil

Transport Layer Security chiffre et authentifie HTTP, le courriel et bien d’autres protocoles entre clients et serveurs. TLS protège les octets en transit contre l’écoute passive et beaucoup d’attaques actives quand les certificats sont validés. Cela ne remplace pas le hachage des mots de passe au repos ni l’évitement de secrets dans des URL qui finissent dans les journaux.

Hachage : empreintes à sens unique

Les fonctions de hachage cryptographiques mappent une entrée arbitraire vers un digest de taille fixe. De petits changements d’entrée avalanche le résultat. SHA-256 sert au contrôle d’intégrité et au content addressing ; ce n’est pas à lui seul un algorithme de stockage de mots de passe, car les GPU peuvent brute-forcer des mots de passe courts sans ralentissement ni sel.

Hachage de mots de passe

• Utilisez des hachages dédiés aux mots de passe : bcrypt, scrypt, Argon2 ou PBKDF2 avec des facteurs de travail élevés.
• Stockez un sel unique par utilisateur pour que les tables arc-en-ciel échouent.
• Poivre optionnel (secret côté serveur) pour une défense en profondeur bien gérée.
• Ne chiffrez jamais les mots de passe de façon réversible pour la vérification à la connexion — comparez les digests avec une égalité en temps constant.

L’outil sha256-hash de SmartKitio illustre SHA-256 pour les sommes de contrôle et l’apprentissage. Pour un vrai stockage de mots de passe, suivez OWASP et les bibliothèques de plateforme — pas un seul passage de hachage rapide.

La compression est un autre axe

gzip et Brotli réduisent les réponses HTTP. JPEG et WebP perdent de l’information pour les photos. La compression n’est ni encodage pour la sécurité du transport ni chiffrement. Les secrets compressés fuient encore des motifs de longueur dans certains modèles de menace, et il ne faut jamais compresser puis chiffrer naïvement sans comprendre les attaques de type CRIME/BREACH sur la compression HTTP.

Idées reçues qui survivent aux audits

1. « On met la clé API en Base64, donc c’est sécurisé. » — N’importe qui peut décoder.
2. « On a chiffré la base, donc TLS ne compte pas. » — Données en mouvement et au repos sont des contrôles distincts.
3. « On a haché une fois avec SHA-256. » — Les hachages rapides suffisent mal pour des mots de passe à faible entropie.
4. « L’encodage URL cache le mot de passe dans la query string. » — Il reste dans l’historique, les journaux et les en-têtes Referer.
5. « Le JWT est chiffré parce qu’il a l’air brouillé. » — Les JWT sont souvent seulement signés (JWS) ou utilisent JWE quand le chiffrement est requis.

Exemples travaillés

Les outils Base64 et URL de SmartKitio s’exécutent dans le navigateur pour des transformations rapides ; les guides base64-encoding-vs-encryption précisent quand ces transformations sont appropriées. Servez-vous-en pour apprendre et déboguer — pas pour « sécuriser » des secrets.