tools / aes
aes/
Chiffrement et déchiffrement symétrique AES. Mode, padding, formats de la clé et de l'IV, jeu de caractères : tout est réglable, les résultats sont identiques à ceux de Java et CryptoJS, et votre clé ne quitte jamais le navigateur.
Texte clair
Texte chiffré
Historique
Chaque chiffrement ou déchiffrement réussi est enregistré automatiquement. Les 20 derniers sont conservés, uniquement dans le navigateur de cet appareil. Les clés ne sont jamais enregistrées, mais les IV et les textes clairs déchiffrés le sont : sur un ordinateur partagé, videz l'historique quand vous avez terminé.
AES, DES et RSA : ce que c'est et en quoi ils diffèrent
AES et DES sont des chiffrements symétriques : la même clé chiffre et déchiffre, comme une clé unique qui ferme et ouvre la porte. Ils sont rapides et conviennent aux gros volumes de données ; la difficulté est de transmettre cette clé à l'autre partie en toute sécurité.
DES est un ancien standard des années 1970 dont la clé effective ne fait que 56 bits : du matériel dédié ou des grappes d'ordinateurs peuvent aujourd'hui la retrouver par force brute. Il ne sert donc que pour dialoguer avec d'anciens systèmes qui l'utilisent encore. AES a remplacé DES comme standard. Il utilise des clés de 128, 192 ou 256 bits, n'a aucune attaque pratique connue à ce jour et reste le choix par défaut pour chiffrer des données.
RSA est asymétrique : il y a une paire de clés. La clé publique peut être donnée à n'importe qui et sert à chiffrer ; la clé privée reste chez vous et sert à déchiffrer, comme une boîte aux lettres où tout le monde peut glisser un courrier mais que vous seul pouvez ouvrir. Pas besoin de convenir d'une clé commune à l'avance, mais RSA est lent et ne peut chiffrer que quelques centaines d'octets à la fois. Les systèmes réels combinent souvent les deux : RSA chiffre une clé AES générée au hasard pour l'autre partie, et AES chiffre les données elles-mêmes.
Qu'est-ce qu'un mode de chiffrement, et lequel choisir ?
AES chiffre 16 octets à la fois ; le mode décide comment des données plus longues sont découpées en blocs et comment les blocs sont reliés entre eux. ECB chiffre chaque bloc séparément : un contenu identique donne un texte chiffré identique, ce qui laisse apparaître des motifs, donc à éviter. CBC mélange chaque bloc avec le bloc chiffré précédent avant de le chiffrer, et le premier bloc avec l'IV ; c'est le choix le plus courant. CFB, OFB et CTR transforment AES en un flux de clé combiné par XOR avec les données octet par octet, sans besoin de padding. GCM ajoute un tag d'authentification à CTR : si le texte chiffré a été modifié, le déchiffrement échoue. C'est le mode recommandé aujourd'hui.
À quoi servent l'IV et le padding ?
L'IV (vecteur d'initialisation) fait que le même contenu est chiffré différemment à chaque fois. Il n'a pas besoin d'être secret et peut voyager avec le texte chiffré, mais il ne faut jamais en réutiliser un avec la même clé, surtout en GCM. Tous les modes sauf ECB ont besoin d'un IV : 12 octets sont recommandés pour GCM, et les autres modes exigent exactement 16 octets.
ECB et CBC exigent que la longueur des données soit un multiple de 16 octets ; les données plus courtes sont complétées selon le padding choisi. PKCS5Padding et PKCS7Padding sont identiques pour AES et sont les plus courants. ZeroPadding complète avec des zéros et retire tous les octets nuls de fin au déchiffrement : un texte clair qui se termine lui-même par des octets nuls les perd. NoPadding n'ajoute rien, c'est donc à vous de respecter la longueur. GCM n'utilise pas de padding.
Correspondance avec Java et CryptoJS
Cipher.getInstance("AES/CBC/PKCS5Padding") en Java correspond à CBC avec PKCS5Padding ; un simple "AES" donne par défaut ECB avec PKCS5Padding. En Java, CTR et GCM ne fonctionnent qu'avec NoPadding, et le tag GCM doit faire de 96 à 128 bits. CryptoJS.pad.Pkcs7 de CryptoJS correspond à PKCS7Padding, et ZeroPadding, AnsiX923, Iso10126 et Iso97971 portent le même nom. Si vous passez une phrase secrète sous forme de chaîne à CryptoJS.AES.encrypt, la bibliothèque dérive elle-même la clé et produit un résultat commençant par U2FsdGVkX1 ; cet usage n'est pas pris en charge ici, fournissez plutôt une clé et un IV de 16, 24 ou 32 octets.
Que sont le tag et l'AAD de GCM ?
Le tag est la valeur de contrôle calculée par GCM ; ce sont les derniers octets du texte chiffré (16 octets pour un tag de 128 bits). L'AAD est une donnée authentifiée additionnelle, par exemple un en-tête de message. Elle n'est pas chiffrée mais entre dans le contrôle : il faut saisir la même AAD au déchiffrement, sinon la vérification échoue.
Questions fréquentes
Que faire face à « La clé fait N octets » ou « L'IV fait N octets » ?
Vérifiez d'abord que le format est le bon : les mêmes 32 caractères font 32 octets en format string, mais seulement 16 octets en hex. Une clé AES doit faire 16, 24 ou 32 octets et, hors ECB et GCM, l'IV doit faire exactement 16 octets ; rien n'est complété par des zéros ni tronqué à votre place, et le nombre d'octets actuel s'affiche à côté des libellés Clé et IV. En format string, le décompte suit le jeu de caractères choisi : une lettre accentuée comme é en occupe 2 et un caractère chinois 3 en UTF-8. Si votre backend traite d'abord la phrase secrète, par exemple en la complétant par des zéros ou en la hachant, calculez d'abord les octets finaux et saisissez-les en hex ou base64.
Que faire quand le déchiffrement indique un padding non valide ?
Cela signifie que le dernier bloc déchiffré ne respecte pas la règle de padding choisie. En général, la clé, l'IV, le mode ou le padding diffère de ce qui a servi au chiffrement, ou le texte chiffré a été copié de façon incomplète. Comparez chaque paramètre avec ceux du côté chiffrement ; un mauvais format de clé ou de texte chiffré (hex ou base64) provoque la même erreur. ZeroPadding et NoPadding ne vérifient pas le padding et ne déclenchent donc pas cette erreur, mais le résultat est illisible si les paramètres sont faux.
Le début du texte déchiffré est illisible, ou le message dit que le résultat n'est pas un texte UTF-8 valide
Vérifiez d'abord l'IV. Quand le texte chiffré dépasse un bloc, un IV incorrect en mode CBC ou CFB n'abîme que le premier bloc de 16 octets : le reste est correct et aucune erreur de padding n'apparaît, donc le début est illisible et la suite est juste. Si le message indique que le résultat n'est pas un texte valide, le jeu de caractères peut différer de celui du chiffrement, par exemple si l'autre partie utilisait GBK. Passer le format de sortie sur hex permet de vérifier d'abord les octets déchiffrés eux-mêmes.
Que faire quand le déchiffrement GCM indique que la vérification du tag a échoué ?
Cela signifie que la clé, l'IV, l'AAD ou la longueur du tag diffère de celle du chiffrement, ou que le texte chiffré a été modifié. Les derniers octets de l'entrée sont traités comme le tag, avec la longueur réglée dans l'option « Longueur du tag » (128 bits par défaut, soit 16 octets) ; le texte chiffré et le tag doivent donc être saisis ensemble. Si l'autre partie vous donne le tag séparément, ajoutez-le d'abord à la fin du texte chiffré. Le format de l'AAD est hex par défaut : changez-le quand vous saisissez du contenu string, et si aucune AAD n'a servi au chiffrement, laissez-la vide au déchiffrement.
Mon résultat ne correspond pas à celui de Java, Python ou d'un autre backend. Comment diagnostiquer ?
Vérifiez dans cet ordre : le mode et le padding, le format et le nombre d'octets de la clé et de l'IV, le jeu de caractères, puis les formats d'entrée et de sortie. Le texte clair au format string n'est pas rogné : un saut de ligne en trop à la fin donne d'autres données. CTR, CFB et OFB appliquent aussi ici le padding choisi, donc avec PKCS5Padding le texte chiffré est plus long que le texte clair ; si le backend utilise NoPadding, choisissez aussi NoPadding ici. Le CFB d'ici est la variante à bloc complet de 128 bits, il ne correspondra donc pas à un backend qui utilise CFB8.
Le texte chiffré doit-il être en hex ou en base64, et que se passe-t-il si je me trompe ?
Suivez ce que produit l'autre partie : un texte composé uniquement de 0-9 et a-f est du hex, et un texte avec des lettres majuscules et minuscules, des + ou /, ou un = final est du base64. Se tromper au déchiffrement n'échoue pas toujours tout de suite, car tous les caractères hex sont aussi des caractères base64 valides ; vous obtenez simplement de mauvais octets, ce qui apparaît plus tard sous la forme « n'est pas un multiple de 16 » ou d'un padding non valide. Le base64 avec - et _ (la forme compatible URL) ou avec des = manquants est accepté, et les espaces, les deux-points et le préfixe 0x du hex sont ignorés.
Que stocke l'historique, et est-il envoyé quelque part ?
Il reste uniquement dans le localStorage du navigateur de cet appareil et n'est jamais envoyé : le code de la page ne fait aucune requête réseau. Une entrée est ajoutée après chaque chiffrement ou déchiffrement réussi, 20 sont conservées au maximum, et rien n'est enregistré si l'entrée ou le résultat dépasse 20 000 caractères. Une entrée contient les paramètres, l'IV, l'AAD, l'entrée et le résultat, plus une empreinte de 8 caractères dérivée de la clé (les caractères après le # dans chaque entrée, qui permettent de savoir s'il s'agit de la même clé), mais jamais la clé elle-même : après avoir cliqué sur « Charger », vous devez donc saisir à nouveau la clé. Chaque entrée peut être supprimée individuellement, et sur un ordinateur partagé, cliquez sur « Vider l'historique » quand vous avez terminé.
Peut-il générer une clé ou un IV aléatoire ?
Non. Il n'y a pas de bouton de génération : vous saisissez vous-même la clé et l'IV. Le même texte clair, la même clé, le même IV et les mêmes paramètres donnent toujours le même résultat ; seul le padding ISO10126 mélange des octets aléatoires et le fait donc varier. Quand vous avez besoin de valeurs aléatoires, générez-les vous-même : par exemple, openssl rand -hex 16 en ligne de commande affiche 16 octets, que vous pouvez saisir avec le format réglé sur hex.