Il y a tout un tas de moyen de crypter des trucs, et pas que du texte. En soi le texte c'est des bits, les algorithmes de chiffrement symétriques (ce qui signifie en (très) gros qu'ils utilisent un mot de passe comme clé de chiffrement) modernes chiffrent par blocs de bits d'une certaine t'aille. Enfin, on s'en fout.

Sous Linux on a tout un tas d'options:

• gpg — Il y a une option --symmetric pour utiliser AES;
• openssl — Encore plus simple;
• Utilitaires en tout genre comme ccrypt;
• 7z, zip, et les autres.

Par ex. avec OpenSSL on est bien dans la philosophie UNIX qui va bien et ce serait simple de créer un alias plus court de ce genre de commandes:

cat super_fichier_texte_secret.txt | openssl enc -e -aes-256-cbc -pbkdf2 -a -salt > fichier_crypte.txt

Pour décrypter, on remplace l'option -e par -d de la commande openssl.

Pour Windows il y a toujours 7zip et euh... Winrar. Bien que ces utilitaires sont surtout prévus pour compresser des trucs et pas chiffrer du texte.

Pour ce relativement étrange cas d'utilisation d'encryption texte, il y a quelques outils en ligne mais j'ignore comment ils ont été écrits et même s'ils prétendent utiliser exclusivement JavaScript en local, pour bien faire il faudrait vérifier chaque fois et c'est très compliqué étant donné que tout le monde "minimise" son JavaScript de nos jours (ce qui est une bonne chose hein, faut sauver la planète) et que j'ai pas toujours que ça à faire.

Comme d'hab je me retrouve à réinventer la roue parce que de toutes façons ma roue a moins de dépendances foireuses et puis c'est ma roue que je connais bien et je sais ce que j'ai mis dedans comme... Ingrédients de roue. Analogie terminée.

Le produit final est ici: https://tools.dkvz.eu/crypto

L'aubaine: il existe une "nouvelle" API de sécurité supportée par tous les navigateurs modernes qui contient déjà tout ce dont j'ai besoin. Ce qui signifie: pas de dépendances et donc encore moins de risques en plus de la tranquilité de ne pas avoir trop de pull requests de dependabot parce que 98% des paquets npm dépendant de lodash.

L'idée est d'utiliser AES en mode AES-GCM qui a l'air plus flexible que d'utiliser le grand classique AES-CBC et qui inclus un système de vérification de l'intégrité du message que je sais pas trop comment ça marche ni si c'est efficace mais je prend.

Il reste quelques décisions à prendre sur plusieurs paramètres d'encryption là où d'autres outils en ligne pourraient prendre d'autres décisions et obtenir un résultat complètement différent. En résumé, pour décrypter un message chiffré en AES-TRUC il faut absolument que tous les paramètres de chiffrement soient les mêmes et que les éléments tels que le sel ou le vecteur d'intiialisation se trouvent au même endroit dans le message final.

Qu'est-ce que tu nous raconte là dis donc j'ai rien compris alors, bon sang.

Oui je sais, peut-être j'explique plus loin, ou pas parce que c'est une brève ce truc normalement (lol).

Dérivation

Pour l'encrytion, on commence par DERIVER LA CLE, ce qui consiste à passer votre mot de passe nul dans une moulinette infernale de sorte d'obtenir toujours la même taille de clé même si votre mot de passe fait deux lettres — C'est cette clé qui sera utilisée pour le chiffrement.

La fonction de dérivation présente déjà quelques paramètres importants à définir (pour les curieux c'est PBKDF2 mais je vous conseille pas d'ouvrir cet article) et doit rendre extrèmement difficile la tâche de retrouver votre mot de passe à partir de la clé dérivée. Quand on sait ça et qu'en plus ces clés ont toujours la même taille, on se doute qu'il y a un algorithme de hachage (son choix est un des paramètres) impliqué dans cette sombre affaire.

Si vous êtes un petit peu familiers avec ce type d'algorithme, vous savez sans doute qu'on les utilise générallement avec un "sel" (qui n'est pas secret mais doit être aléatoire) qui va représenter un autre de nos paramètres (en terme de taille et où le stocker).

Le chiffrement

On commence par générer quelques trucs aléatoirement en utilisant le générateur aléatoire de l'API de sécurité. Par ex. pour le vecteur d'initialisation (me demandez pas ce que c'est):

const iv = crypto.getRandomValues(new Uint8Array(ivLength))

On chiffre ensuite le texte, ce qui nous donne un tableau de bytes (dit aussi octets).

C'est là qu'il s'agit de décider où on colle le sel qui était utilisé pour la dérivation de la clé, et le vecteur d'initialisation (IV) que l'on vient de créer. J'ai décidé de les placer à la fin , d'abord le sel puis l'IV.

Pour décrypter il faudra récupérer ces valeurs, ce qui implique de connaître exactement leur taille en bits.

Pour finir j'encode en base64 (ce qui est étrangement horriblement difficile en JavaScript pour des raisons d'encodage moisi) histoire d'avoir quelque chose de facilement exportable dans tous les encodages, sans caractères spéciaux qui la font mal.

J'ai absolument rien compris à ce que j'ai copié collé:

Il y a aussi cette chaine d'opérateurs ternaires qui est de toute beauté en obscurantisme:

function b64ToUint6(nChr) {

  return nChr > 64 && nChr < 91 ?
    nChr - 65
    : nChr > 96 && nChr < 123 ?
      nChr - 71
      : nChr > 47 && nChr < 58 ?
        nChr + 4
        : nChr === 43 ?
          62
          : nChr === 47 ?
            63
            :
            0

}

Même en Perl on oserait pas faire ça.

Conclusion

C'est pas vraiment une conclusion en fait, cette conclusion.

Tant qu'à faire je me suis aussi mis à Tailwind étant donné que ça a l'air d'être LE truc à la mode. Et c'est vrai que c'est pas mal et vous inquiétez pas je vais pas subtilement transformer cette brève trop longue (oh ben ça alors) en article sur Tailwind, ce sera pour une autre fois. Peut-être.

Je bosse sur un starter kit perso pour créer des petits sites, ce qui me permettait aussi de voir comment se comporte la toute dernière version de Webpack et c'est basé sur Tailwind — J'ai complètement balancé SASS/SCSS puisque PostCSS combiné aux progrès du CSS de base ont des solutions pour tout de nos jours.

J'avais dit que m'étalerais pas là dessus mais il faut avouer que pour le prototypage et le développement rapide en général, c'est assez chouette Tailwind.

Il y a eu un certain progrès depuis l'époque où j'écrivais un bidule de chiffrement de César en Visual Basic.