tools / des
des/
Chiffrement et déchiffrement symétrique DES, pour dialoguer avec d'anciens systèmes qui utilisent encore DES. 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 ?
DES chiffre 8 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 DES en un flux de clé combiné par XOR avec les données octet par octet, sans besoin de padding.
Clé, IV et padding
Une clé DES fait 8 octets, mais le bit de poids faible de chaque octet est un bit de parité qui n'entre pas dans le calcul : la clé effective ne fait donc que 56 bits. Si la clé dépasse 8 octets, seuls les 8 premiers sont utilisés, comme avec DESKeySpec en Java et CryptoJS ; une clé plus courte est refusée. Tous les modes sauf ECB exigent un IV de 8 octets. Il n'a pas besoin d'être secret, mais il ne faut jamais en réutiliser un avec la même clé.
ECB et CBC exigent que la longueur des données soit un multiple de 8 octets ; les données plus courtes sont complétées selon le padding choisi. PKCS5Padding et PKCS7Padding sont identiques pour DES 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.
Correspondance avec Java et CryptoJS
Cipher.getInstance("DES/CBC/PKCS5Padding") en Java correspond à CBC avec PKCS5Padding ; un simple "DES" donne par défaut ECB avec PKCS5Padding. En Java, CTR ne fonctionne qu'avec NoPadding. Dans CryptoJS.DES.encrypt, les modes et les paddings portent les mêmes noms, et CryptoJS.pad.Pkcs7 correspond à PKCS7Padding. Pour un nouveau système, utilisez plutôt AES.
Questions fréquentes
Peut-il chiffrer et déchiffrer du 3DES (DESede, TripleDES) ?
Non, seul le DES simple est implémenté ici. Une clé 3DES fait 16 ou 24 octets ; collée ici, seuls ses 8 premiers octets sont utilisés, et le résultat diffère donc de celui du 3DES. Le champ Clé affiche d'ailleurs « seuls les 8 premiers octets sont utilisés ». Pour du 3DES, utilisez un outil compatible DESede.
Que faire face à « La clé fait N octets ; une clé DES exige au moins 8 octets » ?
Moins de 8 octets provoque une erreur, et rien n'est complété par des zéros à votre place : complétez vous-même la clé jusqu'à 8 octets. Une erreur plus fréquente est le mauvais format : si une clé hex de 16 caractères est saisie avec le format de clé réglé sur string, elle est traitée comme 16 octets de texte et seuls les 8 premiers caractères sont utilisés. Aucune erreur n'apparaît, seulement la remarque « seuls les 8 premiers octets sont utilisés » à côté du champ Clé et sous le résultat, et la sortie ne correspondra pas. En format string, le décompte suit le jeu de caractères choisi : un caractère chinois occupe 3 octets en UTF-8.
Que faire face à « ce mode exige un IV d'exactement 8 octets » ?
Un IV DES doit faire exactement 8 octets, et non les 16 octets d'AES, dans tous les modes sauf ECB. Une clé de plus de 8 octets est tronquée à ses 8 premiers, mais pas l'IV : trop long ou trop court, c'est une erreur, et un IV de 16 octets repris de paramètres AES doit être ramené à 8 octets. Vérifiez aussi le format : 16 caractères hex font 8 octets, alors que les mêmes 16 caractères en format string font 16 octets. ECB n'utilise pas d'IV et masque la ligne IV.
Que faire face à « padding non valide » ou « n'est pas un multiple de 8 » au déchiffrement ?
Une longueur de texte chiffré qui n'est pas un multiple de 8 signifie en général une copie incomplète, ou hex et base64 inversés. Un padding non valide signifie en général que la clé, l'IV, le mode ou le padding diffère de ce qui a servi au chiffrement. ZeroPadding et NoPadding ne vérifient pas le padding et ne déclenchent donc jamais 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 8 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.
Mon résultat ne correspond pas à celui de Java ou CryptoJS : comment diagnostiquer ?
Vérifiez dans cet ordre : mode et padding, format et nombre d'octets de la clé et de l'IV, jeu de caractères, formats d'entrée et de sortie. Un texte clair au format string n'est pas rogné : un saut de ligne en trop à la fin donne des données différentes. CTR, CFB et OFB appliquent aussi ici le padding choisi : avec PKCS5Padding, le texte chiffré est plus long que le texte clair ; si le back-end utilise NoPadding, choisissez aussi NoPadding ici. CFB est ici la variante à bloc complet de 64 bits : elle ne correspondra pas à un back-end qui utilise CFB8.
Le résultat de CryptoJS.DES.encrypt commence par U2FsdGVkX1. Peut-on le déchiffrer ici ?
Non. Quand vous passez une simple chaîne comme clé à CryptoJS.DES.encrypt(message, chaîne), CryptoJS la traite comme une phrase secrète : il ajoute un sel aléatoire et dérive la clé et l'IV à la manière d'OpenSSL, et le résultat commence par U2FsdGVkX1. Ce format n'est pas pris en charge ici. Pour obtenir le même résultat que cet outil, convertissez la clé en octets dans CryptoJS avec CryptoJS.enc.Utf8.parse avant de la passer, et définissez explicitement iv, mode et padding.
Que stocke l'historique, et est-il envoyé quelque part ?
L'historique n'existe que dans le localStorage du navigateur de cet appareil et n'est jamais envoyé : le code de la page n'effectue aucune requête réseau. Une entrée est ajoutée après chaque chiffrement ou déchiffrement réussi, 20 au maximum sont conservées, et toute opération dont le texte saisi ou le résultat dépasse 20 000 caractères n'est pas enregistrée. Une entrée contient les paramètres, l'IV, le texte saisi et le résultat, plus une empreinte de 8 caractères dérivée des 8 premiers octets de la clé (les caractères après le # dans chaque entrée, qui servent à savoir s'il s'agit de la même clé), mais jamais la clé elle-même : après avoir cliqué sur « Charger », il faut donc ressaisir la clé. Chaque entrée peut être supprimée individuellement, et sur un ordinateur partagé, cliquez sur « Vider l'historique » quand vous avez terminé.