Comment choisir un outil de chiffrement

Le chiffrement peut s'exécuter dans le navigateur avant l'envoi, sur le serveur après l'envoi, ou entre les deux. Le lieu détermine ce que le fournisseur peut voir. Dès qu'un texte en clair ou une clé brute traverse le réseau, son personnel, ses journaux et ses sauvegardes entrent dans votre surface d'attaque, indépendamment des intentions.

Ouvrez les outils de développement et observez l'onglet Réseau pendant que vous chiffrez une courte chaîne de test. Un outil côté client ne transmet rien à cette étape. Un outil côté serveur envoie votre texte et renvoie des données chiffrées. Cette observation vaut plus que n'importe quelle liste de fonctions.

La garde de la clé est la deuxième question, et elle tranche souvent les autres. Beaucoup d'approches zéro connaissance dérivent une clé dans le navigateur à partir de votre phrase secrète et ne la transmettent jamais. Vous gagnez un contrôle réel et vous perdez la récupération : personne, pas même l'exploitant, ne peut reconstruire la clé à partir de ce que le serveur stocke.

Certains services conservent une copie de votre clé pour restaurer un compte. C'est un échange légitime, à lire comme tel. Si un exploitant peut restaurer vos données sur demande, toute personne qui obtient son accès le peut aussi. Posez la question : pouvez-vous déchiffrer mes données sans ma phrase secrète ?

Un outil sérieux nomme ses primitives. AES-256-GCM est spécifié dans FIPS 197 et NIST SP 800-38D et assure la confidentialité ainsi qu'une étiquette d'authentification qui détecte toute modification. ChaCha20-Poly1305, défini dans la RFC 8439, convient lorsque l'accélération matérielle d'AES manque. La dérivation de clé compte autant : PBKDF2 est défini dans la RFC 8018, Argon2 dans la RFC 9106, et le nombre d'itérations ou le coût mémoire fixe le prix d'une devinette sur votre phrase secrète.

Les paramètres appartiennent à la documentation, à côté du nom des algorithmes. Un outil qui annonce AES-256 sans mode, longueur de sel, gestion du nonce ni coût de dérivation vous laisse deviner l'essentiel.

Commencez par écrire l'adversaire dont vous vous défendez : un ordinateur volé, un poste partagé, une réquisition adressée au fournisseur, un observateur du réseau ou une collègue sur le même compte. Aucun outil ne les couvre tous. Le chiffrement côté client en couvre plusieurs et n'aide pas contre un poste compromis. Si la récupération compte plus que la garde exclusive, choisissez un service qui l'assure et le dit. Les extensions malveillantes, les enregistreurs de frappe et un système hostile voient votre texte en clair avant qu'une primitive ne s'exécute.

Vérifier signifie reproduire une affirmation sur sa propre machine. La W3C Web Crypto API est documentée sur MDN ; la même primitive s'exécute dans la console via crypto.subtle.generateKey, avec AES-GCM et une clé de 256 bits. Pour un fichier, déchiffrez un échantillon avec une implémentation indépendante comme crypto.createDecipheriv de Node, puis comparez le résultat. Un code source public n'aide que si vous lisez le code réellement exécuté : vérifiez que le paquet livré correspond aux sources publiées.

La conservation détermine combien de temps survivent les données chiffrées, les métadonnées et les journaux. Un service qui ne stocke rien n'a rien à remettre ; celui qui garde des blocs chiffrés a besoin d'une règle d'expiration claire. Cherchez une durée écrite, une suppression qui retire vraiment l'objet et une phrase sur ce qui subsiste dans les sauvegardes.

Le mode hors ligne relève de la même revue. Si la page chiffre encore une fois la connexion coupée, la cryptographie est locale et l'outil reste utilisable en avion, dans un réseau verrouillé ou après la disparition du service. Un outil qui échoue sans aller-retour réseau travaille sur un serveur, quoi que suggère l'interface.