Chiffrer du texte dans le navigateur est un aller-retour avec garde : le texte clair est transformé en chiffré avec une clé, et une étiquette d'authentification de 16 octets est jointe, de sorte que quiconque modifie le moindre bit du chiffré en route est détecté. Chiffrement/Déchiffrement AES exécute cet aller-retour entièrement dans le navigateur avec AES-GCM : un texte clair de 12 octets devient un chiffré de 28 octets, une clé hexadécimale de 32, 48 ou 64 caractères choisit AES-128, 192 ou 256, et l'IV de 24 caractères fait 12 octets. La sortie est en base64 — 40 caractères pour cet exemple de 12 octets — et le côté déchiffrement refuse tout ce qui a été manipulé. Rien ne quitte la machine.
Ce que GCM ajoute au chiffrement par blocs
L'AES à lui seul est un chiffrement par blocs : il prend 16 octets à la fois et les brouille à travers un nombre fixe de rondes — 10 pour une clé de 128 bits, 12 pour 192, 14 pour 256. Un chiffrement par blocs seul n'occulte pas la longueur du message, n'accepte pas un message qui n'est pas un multiple de 16 octets, et ne dit pas si le chiffré a été modifié en route. GCM ajoute trois choses : il fait tourner le chiffreur en mode compteur, de sorte qu'un message de n'importe quelle longueur passe ; il dérive un flux de clés XORé au texte clair, qui est ce qui cache le contenu ; et il calcule une étiquette d'authentification de 16 octets sur le chiffré avec un hachage à clé. L'étiquette est la garde : retournez un bit du chiffré et le côté déchiffrement lève une erreur au lieu de rendre de la bouillie. Un générateur de hachage calcule des digestes de la même famille mais sans clé, pour l'intégrité et la déduplication, et un digest ne se retourne pas, donc le hachage seul ne peut jamais être un chiffrement — l'étiquette de GCM prend l'idée du hachage et la dote d'une clé, ce qui rend son attachement sûr.
La clé, l'IV et la paire qui ne doit pas se répéter
La clé est la matière : 32 caractères hexadécimaux font 16 octets, 48 en font 24, 64 en font 32, si bien que les trois longueurs légales choisissent AES-128, AES-192 et AES-256, et la clé reste dans un identifiant non extractible au sein de la Web Crypto après l'importKey, sans être stockée ni envoyée. L'IV (vecteur d'initialisation) est de 24 caractères hexadécimaux, 12 octets, et doit différer de tout autre IV utilisé avec la même clé. C'est la paire qui ne doit pas se répéter : la même clé avec le même IV deux fois est l'échec qui brise GCM, parce que le flux de clés du compteur serait identique dans les deux exécutions et le second message donnerait à l'attaquant la capacité d'écorcer le premier. L'outil se souvient des paires clé-IV déjà employées dans la session et affiche un avertissement dès que vous tentez de chiffrer de nouveau avec l'une d'elles. Pour comparer, un générateur HMAC utilise le même type de hachage à clé pour le travail inverse : il authentifie un message sans le cacher, de sorte que le HMAC répond si le contenu est intact et à vous, tandis que GCM répond cela et s'il est en plus secret.
D'où vient l'aléatoire
Lorsque la page charge, l'outil remplit les deux champs pour vous : une clé hexadécimale aléatoire de 64 caractères, 32 octets, et un IV hexadécimal aléatoire de 24 caractères, 12 octets, générés par le même chemin getRandomValues de la Web Crypto qui porte le chiffrement. L'aléatoire est ce qui garde l'IV unique : un IV aléatoire de 12 octets a une probabilité de collision négligeable entre un petit nombre de messages, et une clé neuve élimine même cela. Si vous générez des identifiants dans le même navigateur, le générateur UUID puise dans la même source d'aléatoire pour les UUID de version 4, et la même prudence s'applique : l'aléatoire est un approvisionnement, pas un réglage, et le navigateur est le distributeur. Traitez les deux champs générés comme vous traiteriez un passeport — ils partent avec vous et ne se partagent pas.
Lire la sortie en base64
Le chiffré est binaire, si bien que l'outil le peint en base64, qui est l'encodage qui mappe chaque groupe de trois octets en quatre caractères. C'est pourquoi le texte clair de 12 octets ne revient pas comme 12 caractères : les 28 octets de chiffré, les 12 plus l'étiquette de 16, s'encodent en 40 caractères base64, le groupe final absorbant le reste en bourrage. La croissance est stable : 100 octets de texte clair donnent 116 octets de chiffré, soit 156 caractères base64, et 1000 octets donnent 1016, soit 1356 caractères. Les 16 octets en plus sont la même étiquette à chaque fois, si bien que sur les messages longs le surcoût est négligeable et sur les courts il se voit. Quand il faut passer les octets à un endroit qui attend l'encodage brut, l'encodeur/décodeur Base64 convertit entre la forme texte et les autres représentations sans toucher au contenu.
La clé est tout le système
L'AES-GCM n'est fort que comme la clé derrière lui, et une clé est un secret au même titre qu'un mot de passe : sa force est fonction de la longueur et de l'imprévisibilité, et sa gestion consiste à ne pas la répéter et à ne pas l'écrire où quiconque peut la lire. L'outil ne juge pas votre clé — il accepte n'importe quelle chaîne hexadécimale de longueur paire entre 32 et 64 —, mais le contrôle honnête est celui qu'un vérificateur de force de mot de passe applique aux mots de passe, traduit en hexadécimal : une chaîne de 64 caractères qui est un motif répété est 32 octets de matière et bien moins de 256 bits d'entropie. Si vous avez besoin de véritable matière de clé plutôt que d'une tapée, le guide du générateur de mots de passe couvre la même discipline de génération et de stockage, et une clé hexadécimale aléatoire se génère par le même chemin d'un clic.
Où l'AES apparaît hors de la boîte
Le même primitif AES-GCM n'est pas un jouet de navigateur : TLS utilise AES-GCM comme l'une de ses suites de chiffrement principales, le chiffrement de disque complet sur les systèmes d'exploitation modernes utilise l'AES, en mode XTS d'ordinaire, et l'API Web Crypto que l'outil appelle est celle que les environnements de paiement, les flux de connexion et les applications offline-first appellent pour le stockage local chiffré. Le but de cet outil est de rendre le primitif inspectable : vous pouvez voir le chiffré exact, le surcoût exact de l'étiquette et le mode exact de défaillance de la détection de manipulation, le tout dans une zone de texte. Les jetons sont l'autre face visible du même stack — un décodeur JWT ouvre l'en-tête et la charge du jeton pour montrer ce qui est signé et ce qui ne l'est pas, qui est le jumeau en lecture seule de ce que le chiffrement fait dans le sens de l'écriture.