Qu'est-ce que le chiffrement côté client ? Votre navigateur fait le travail

Le chiffrement côté client signifie que votre navigateur ou votre application chiffre les fichiers sur votre appareil avant que quoi que ce soit ne touche le réseau. Le serveur ne reçoit que du texte chiffré — une sortie AES-256-GCM indiscernable d'un bruit aléatoire — et la clé de déchiffrement ne quitte jamais le client. C'est l'opposé du chiffrement côté serveur, où le fournisseur détient les clés et peut techniquement lire vos fichiers. L'API Web Crypto (window.crypto.subtle) rend cela possible dans n'importe quel navigateur moderne sans plugins, fonctionnant à environ 2–3 Go/s sur du matériel AES-NI. Des services comme HexaTransfer, SwissTransfer, Tresorit Send et Proton Drive utilisent ce modèle pour garantir que les fichiers restent privés même si le service lui-même est compromis.

Le navigateur comme moteur cryptographique

Il y a cinq ans, un vrai chiffrement nécessitait l'installation d'une application de bureau ou l'utilisation de PGP en ligne de commande. L'API Web Crypto, standardisée par le W3C en 2017, a changé cela. Elle expose AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 et SHA-256 directement au JavaScript dans n'importe quel navigateur grand public — Chrome, Firefox, Safari, Edge.

Les performances ne sont plus un obstacle. Les instructions Intel AES-NI atteignent 3–5 Go/s par cœur pour AES-256-GCM. Les extensions cryptographiques ARM sur les puces Apple M-series et Qualcomm Snapdragon offrent un débit similaire. Chiffrer un fichier de 1 Go dans le navigateur prend environ 300–500 ms sur un ordinateur portable de milieu de gamme.

Le défi restant est la gestion de fichiers plus volumineux que la mémoire du navigateur. L'API Streams et ReadableStream permettent au code de traiter les fichiers en fragments de 4 Mo, en chiffrant chaque fragment indépendamment avec un IV en mode compteur unique. C'est ainsi que les services repoussent le plafond à 10 Go ou plus.

Un flux de chiffrement côté client minimal

Voici la séquence qu'exécute un service typique basé sur navigateur :

// 1. Générer une clé AES aléatoire de 256 bits
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Lire le fichier par fragments
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Chiffrer chaque fragment avec un IV unique de 12 octets
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. Envoyer [iv || ciphertext] au serveur
}

// 5. Exporter la clé et l'intégrer dans le fragment d'URL de partage
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://example.com/d/${fileId}#k=${base64url(keyBytes)}`;

Le serveur voit des octets d'apparence aléatoire, un identifiant de fichier, et rien d'autre. La clé n'existe que dans la mémoire du navigateur de l'utilisateur et dans le fragment d'URL.

Pourquoi c'est meilleur que le chiffrement côté serveur

Le chiffrement côté serveur signifie que le fournisseur déchiffre sur demande — pour générer des vignettes, effectuer des analyses antivirus, traiter des requêtes de recherche ou répondre à des demandes légales. Une divulgation Apple de 2023 a révélé que les sauvegardes iCloud (qui n'étaient pas chiffrées de bout en bout jusqu'au lancement d'Advanced Data Protection) étaient accessibles à Apple et donc aux forces de l'ordre sous demandes valides.

Le côté client inverse cela. Comme la clé n'atteint jamais le fournisseur :

• Les employés malveillants ne voient rien. L'ingénieur avec accès à la base de données obtient du texte chiffré.
• Les réquisitions judiciaires produisent du texte chiffré. Le fournisseur peut répondre aux mandats en remettant le blob chiffré, inutile sans la clé.
• Les violations divulguent du texte chiffré. L'incident LastPass de 2021 l'a montré — les coffres volés étaient chiffrés, et seuls les utilisateurs avec des mots de passe maîtres faibles ont fait face à un risque réel.
• Les pannes du fournisseur ne compromettent pas les données. Même si l'entreprise disparaît, votre copie locale de la clé (l'URL) déchiffre toujours le fichier.

Ce que le serveur peut toujours voir

Le chiffrement côté client protège le contenu des fichiers mais pas tout. Le serveur observe généralement :

• La taille du fichier — la longueur du texte chiffré approxime la longueur du texte en clair (AES-GCM ajoute 16 octets de surcharge par chiffrement, plus les 12 octets d'IV).
• Les adresses IP d'envoi et de téléchargement avec horodatages.
• Les métadonnées de session des poignées de main TLS, y compris l'empreinte TLS du client.
• Les noms de fichiers chiffrés — à moins que les noms de fichiers ne soient inclus dans la charge utile chiffrée, ils peuvent fuiter.

Les bons services côté client chiffrent les noms de fichiers dans l'en-tête du texte chiffré et rembourrage vers des tailles de compartiments (1 Mo, 10 Mo, 100 Mo) pour masquer la taille. Tresorit et Proton Drive documentent leur exposition aux métadonnées de façon explicite.

Chiffrement côté client protégé par mot de passe

De nombreux services permettent aux utilisateurs d'ajouter un mot de passe en plus du fragment d'URL. Le flux :

1. Le navigateur génère un sel aléatoire de 128 bits et dérive une clé avec PBKDF2-HMAC-SHA-256 à 600 000 itérations (recommandation OWASP 2023) ou Argon2id avec memory=64 Mo, iterations=3.
2. Le fichier est chiffré avec la clé dérivée.
3. Le sel va dans le fragment d'URL ; le mot de passe est communiqué hors bande.
4. Le destinataire tape le mot de passe, qui re-dérive la clé localement.

Cela transforme un partage à canal unique (l'URL suffit) en deux facteurs : l'attaquant a besoin à la fois du lien et du mot de passe. PBKDF2 avec 600 000 itérations fait qu'une attaque par force brute hors ligne coûte environ 10 secondes par tentative sur un GPU moderne, donc les mots de passe ont besoin de 40+ bits d'entropie pour résister à des attaquants déterminés — pensez à 10+ caractères issus d'un alphabet varié.

Le déplacement de confiance : du service au code client

Le chiffrement côté client déplace la frontière de confiance. Avant, vous faisiez confiance au service pour gérer correctement votre texte en clair. Maintenant, vous faites confiance au JavaScript que le service expédie à votre navigateur à chaque chargement de page. Une mise à jour malveillante pourrait exfiltrer la clé avant ou pendant le chiffrement.

Trois mesures de mitigation existent, de rigueur variable :

• Subresource Integrity (SRI) pour les balises de script garantit que le hash JS correspond à une valeur connue.
• Audits de code par des entreprises comme Cure53, NCC Group ou Trail of Bits vérifient que la logique de chiffrement est saine.
• Builds reproductibles permettent à des parties indépendantes de confirmer que le code expédié correspond au code source publié.
• Les en-têtes Content Security Policy (CSP) bloquent les scripts tiers qui pourraient altérer le chiffrement.

L'approche la plus stricte, utilisée par pmcrypto de Proton Mail et certains clients Electron, expédie des binaires signés plutôt que du JavaScript frais à chaque visite. Les services basés sur navigateur échangent une partie de cette rigueur contre la commodité de l'installation zéro.

Cas d'usage où le côté client brille

Quelques scénarios où le chiffrement côté client vaut le premier chargement légèrement plus lent :

• Documents juridiques et médicaux. HIPAA 45 CFR § 164.312 et le secret professionnel de l'avocat bénéficient tous deux fortement des architectures aveugles au fournisseur.
• Journalisme et protection des sources. Envoi de documents non expurgés où même l'exposition aux métadonnées présente un risque.
• Propriété intellectuelle d'entreprise. Ordres du jour de conseil, modèles financiers, documents de fusion-acquisition où les menaces internes au niveau du fournisseur de transfert de fichiers constituent un risque réel.
• Dossiers personnels. Avis d'imposition, passeports, résultats médicaux — des fichiers que vous seriez mal à l'aise de voir dans une violation chez un fournisseur.

Pour les fichiers peu sensibles (une photo de réunion, une recette), le chiffrement traditionnel côté serveur convient parfaitement.

Reconnaître le vrai chiffrement côté client

Quatre signes qu'un service effectue vraiment du chiffrement côté client :

1. Les fragments d'URL portent une clé. L'URL de partage contient du texte après # qui ressemble à des octets aléatoires encodés en base64.
2. Les envois sont du texte chiffré. Ouvrez les DevTools → Réseau pendant l'envoi ; le corps de la requête devrait ressembler à des octets aléatoires, pas à votre nom de fichier.
3. Les gros fichiers fonctionnent toujours rapidement. Un vrai flux côté client diffuse des fragments ; il ne ré-envoie pas vers une passerelle de chiffrement côté serveur.
4. La politique de confidentialité dit "nous ne pouvons pas déchiffrer vos fichiers." Associée à un livre blanc technique, pas seulement à du discours marketing.

Services qui passent : le niveau E2EE de SwissTransfer, Tresorit Send, les liens partagés Proton Drive, Mega.nz et HexaTransfer. Services qui ne passent pas : WeTransfer (standard), Google Drive, liens de partage Dropbox.

Mise en pratique

Pour essayer le chiffrement côté client maintenant, ouvrez les DevTools et regardez l'onglet Réseau pendant l'envoi d'un fichier. Vous devriez voir un blob chiffré aller vers le serveur et une clé dans votre barre d'adresse qui n'apparaît jamais dans aucune requête. C'est toute la promesse.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.