Chiffrement côté client et de bout en bout

Côté client, le chiffrement a lieu sur votre appareil, avant que les données n'atteignent qui que ce soit. Le navigateur exécute les opérations cryptographiques et la clé reste entre vos mains. Le chiffrement de bout en bout pose une autre question : qui peut lire le texte en clair entre l'expéditeur et le destinataire ?

Les deux propriétés vont souvent ensemble. Une messagerie qui chiffre sur votre appareil et déchiffre sur celui de votre correspondant est à la fois côté client et de bout en bout. Un outil web qui chiffre un fichier localement et n'envoie que le texte chiffré est côté client, mais pas de bout en bout, faute de seconde extrémité. Une notion décrit le lieu, l'autre le trajet.

Dans le modèle côté client, la clé reste sur votre appareil et n'est jamais transmise. Vous pouvez la dériver d'une phrase secrète avec PBKDF2 (RFC 8018) ou générer une clé aléatoire de 256 bits avec l'API Web Crypto du W3C. Le chiffrement utilise ensuite AES-256-GCM, normalisé dans la FIPS 197 et la NIST SP 800-38D.

Dans un modèle de bout en bout, chaque extrémité détient son propre matériel de clé et le relais transmet un texte chiffré qu'il ne peut pas lire. L'échange de clés suit des protocoles comme TLS (RFC 8446) ou un double ratchet, et la confidentialité persistante limite ce qu'une clé volée expose. Un outil côté client n'a donc aucun annuaire de clés.

Le chiffrement de bout en bout vise l'interception et un relais honnête mais curieux : qui enregistre le trafic n'obtient que du texte chiffré. Le chiffrement côté client ajoute une seconde cible, la couche de stockage. Quand un fournisseur conserve votre bloc chiffré, une intrusion ou une réquisition livre des données inutilisables sans votre clé.

Aucun des deux modèles ne protège les extrémités elles-mêmes. Si un logiciel malveillant s'exécute sur l'appareil où vous saisissez la phrase secrète, l'attaquant voit le texte en clair et les clés ensemble. La plupart des comparaisons omettent ce point.

Un navigateur est un environnement partagé. Tout script de la même origine peut appeler l'API Web Crypto de votre outil, lire vos saisies et envoyer le résultat ailleurs. Une faille intersite ou une extension trop large pèse donc plus que l'algorithme. Vérifiez-le vous-même : ouvrez les outils de développement et exécutez crypto.subtle.generateKey({ name : "AES-GCM", length : 256 }, true, ["encrypt", "decrypt"]). Le true du deuxième argument rend la clé exportable ; à false, aucun script ne l'exporte.

Les extensions échappent au contrôle de la page. Un gestionnaire de mots de passe, un outil de capture d'écran ou un lecteur de presse-papiers peut saisir ce que vous tapez avant le chiffrement. Un appareil éteint ne contient que du texte chiffré, mais une session ouverte sur une machine partagée annule le modèle, car le chiffrement protège les données au repos et en transit, pas une session active. L'OWASP le dit aussi.

Les tâches ponctuelles sont le terrain du chiffrement côté client : chiffrer un fichier avant de le téléverser, protéger un extrait que vous collerez dans un courriel, ou travailler hors ligne sans compte. Il échoue comme stratégie de sauvegarde, car un texte chiffré sans clé est perdu. Le chiffrement de bout en bout convient aux conversations suivies entre parties identifiées, où les clés doivent être découvertes et renouvelées.

Deux questions trient la plupart des cas. Les données doivent-elles rester lisibles plus tard par quelqu'un d'autre ? Sinon, le chiffrement côté client avec une clé que vous contrôlez est plus simple et retire le fournisseur de votre périmètre de confiance. Les données circulent-elles entre deux parties qui doivent toutes deux les lire ? Il faut alors une conception de bout en bout avec vérification des clés, et accepter que les métadonnées restent visibles.