Chiffrement de bout en bout expliqué : guide débutant

Le chiffrement de bout en bout (E2EE) signifie que votre fichier est brouillé sur votre appareil avec une clé que seul le destinataire peut reconstituer. Le service de transfert déplace du texte chiffré mais ne détient jamais la clé de déchiffrement : le personnel, les pirates et les réquisitions judiciaires ne peuvent donc pas lire le contenu. En pratique, votre navigateur génère une clé AES aléatoire de 256 bits, chiffre le fichier localement, envoie le texte chiffré, puis place la clé dans le lien de partage après le fragment # — que les navigateurs n'envoient jamais au serveur. C'est toute l'astuce, et c'est ce qui distingue la vraie confidentialité du simple discours marketing.

Ce que "bout en bout" signifie vraiment

Les deux "bouts" sont vous et votre destinataire. Tout ce qui se trouve entre les deux — routeurs FAI, nœuds CDN, serveurs du service de transfert, FAI du destinataire — se situe au milieu. Avec l'E2EE, ces relais intermédiaires ne voient que des octets chiffrés. Comparez cela au chiffrement de la couche transport seul (TLS) : TLS protège les données de votre navigateur jusqu'au serveur, puis le serveur les déchiffre, stocke le contenu en clair et les rechiffre lors du téléchargement par le destinataire. Le niveau standard de WeTransfer fonctionne ainsi. L'entreprise peut (et selon le droit français et européen, doit parfois) remettre des fichiers sur demande légale.

Avec l'E2EE, même si un procureur remet au fournisseur un mandat, ce dernier n'a rien d'autre à livrer que des octets d'apparence aléatoire. C'est pourquoi les journalistes, les avocats et les médecins l'exigent de plus en plus.

Pourquoi TLS seul ne suffit pas

TLS 1.3 est excellent dans ce qu'il fait : empêcher un attaquant dans un café ou un FAI compromis d'espionner la connexion. Mais TLS se termine au serveur. Une fois le tunnel chiffré terminé, le serveur traite le fichier brut. Si ce serveur est compromis — comme c'est arrivé à Dropbox en 2022 quand du code source et certaines données clients ont fuité — TLS n'offre aucune protection pour les fichiers stockés.

L'E2EE ajoute une deuxième couche qui survit à la compromission du serveur. Le fichier est chiffré avant de toucher le réseau et reste chiffré jusqu'à ce que le navigateur du destinataire le déchiffre. Même une extraction complète de la base de données ne révèle que du texte chiffré et des métadonnées.

Le problème de l'échange de clé, résolu

La partie délicate de l'E2EE consiste à transmettre la clé au destinataire sans que le serveur la voie. Les services modernes basés sur navigateur résolvent cela avec l'astuce du fragment d'URL. Un lien de partage ressemble à :

https://hexatransfer.com/download/abc123#k=cle-256-bits-en-base64

Les navigateurs traitent tout ce qui se trouve après # comme un fragment côté client. Quand vous cliquez sur le lien, le serveur ne reçoit que /download/abc123 dans la requête HTTP — le fragment ne quitte jamais votre navigateur. Le JavaScript lit ensuite la clé depuis le fragment, récupère le texte chiffré et le déchiffre localement via la méthode crypto.subtle.decrypt() de l'API Web Crypto.

C'est plus simple que l'échange de clé RSA ou Diffie-Hellman et fonctionne pour quiconque dispose d'un navigateur. La contrepartie : quiconque obtient le lien obtient le fichier, vous devez donc quand même partager les liens par un canal sécurisé (Signal, en personne, un e-mail chiffré).

Ce que le serveur voit par rapport à ce qu'il ne peut pas voir

Avec un E2EE correctement implémenté, les journaux serveur contiennent généralement : un identifiant de fichier aléatoire, la taille du texte chiffré, l'IP d'envoi, l'horodatage et le hash SHA-256 du texte chiffré pour la déduplication. Il ne voit pas : le nom du fichier, le contenu du fichier, l'identité du destinataire, ni la clé de déchiffrement. Les noms de fichiers sont souvent chiffrés avec le contenu et stockés dans l'en-tête du texte chiffré.

Un test utile : demandez au fournisseur ce qu'il transmettrait sous mandat. Un service E2EE honnête répondra "des blobs chiffrés et des journaux IP". S'il peut produire des fichiers en clair, le chiffrement n'est pas de bout en bout.

Les algorithmes sous le capot

Les vraies implémentations E2EE convergent vers une courte liste de primitives bien auditées :

AES-256-GCM pour le chiffrement massif des fichiers. GCM assure à la fois la confidentialité et l'authentification : un texte chiffré altéré échoue au déchiffrement plutôt que de produire des données corrompues.
PBKDF2 avec au moins 100 000 itérations, ou Argon2id, pour dériver des clés à partir de mots de passe quand une protection par mot de passe est ajoutée.
SHA-256 pour les hashes d'intégrité.
TLS 1.3 comme transport externe, car la redondance est peu coûteuse.

Évitez les services utilisant encore AES-CBC sans HMAC (malléable), MD5 ou SHA-1 (compromis), ou PBKDF2 avec moins de 10 000 itérations (craquable par force brute sur des GPU modernes).

E2EE pour le transfert de fichiers vs la messagerie

Signal a popularisé l'E2EE pour la messagerie avec le protocole Double Ratchet, qui fait pivoter les clés après chaque message pour assurer la confidentialité persistante. Le transfert de fichiers n'a pas besoin de cette complexité car il s'agit d'un échange ponctuel — vous ne maintenez pas une conversation continue. Une seule clé symétrique par fichier, générée à chaque envoi, est à la fois plus simple et plus facile à auditer.

Ce dont le transfert de fichiers a besoin et pas la messagerie : des envois par fragments avec reprise (les fichiers peuvent peser 10 Go), une vérification d'intégrité sur tous les fragments, et des liens qui fonctionnent sans que le destinataire ait un compte. Tresorit, Proton Drive, SwissTransfer et HexaTransfer adoptent tous cette approche avec de légères variations.

Vérifier si un service est vraiment de bout en bout

Quatre tests pratiques avant de faire confiance à un fournisseur :

Ouvrez les DevTools → Réseau lors de l'envoi d'un petit fichier. Si vous voyez le contenu en clair dans le corps de la requête, ce n'est pas du chiffrement côté client.
Cherchez la clé dans le fragment d'URL (après #). L'absence de clé dans le fragment signifie généralement que le serveur détient la clé.
Lisez la politique de confidentialité pour y trouver la formulation "nous ne pouvons pas accéder à vos fichiers" accompagnée d'une description technique expliquant pourquoi.
Vérifiez si le code client est auditable — open source ou au moins documenté. Les binaires fermés avec des affirmations E2EE constituent un signal d'alarme.

Services qui passent les quatre tests : SwissTransfer (niveau chiffrement côté client), Tresorit Send, liens de partage Proton Drive et HexaTransfer.

Ce que l'E2EE ne protège pas

L'E2EE n'est pas magique. Il ne vous protège pas contre :

Un terminal compromis. Si votre ordinateur est infecté par un malware, l'attaquant lit les fichiers avant le chiffrement.
Des liens de partage divulgués. Quiconque possède le lien peut télécharger et déchiffrer.
Des mots de passe faibles sur les transferts protégés par mot de passe. PBKDF2 ralentit la force brute, mais "ete2024" tombe en quelques secondes.
La corrélation de métadonnées. Les horodatages, tailles de fichiers et adresses IP peuvent quand même raconter une histoire.

Associez l'E2EE à des liens à durée limitée (24 heures est une valeur par défaut raisonnable), des limites de téléchargement (souvent 1 à 10 téléchargements) et des mots de passe forts pour les transferts sensibles.

Mise en pratique

Pour une vérification rapide : envoyez un fichier test de 5 Mo, ouvrez le lien de partage dans une fenêtre privée sans le fragment (supprimez tout ce qui suit #) et essayez de télécharger. Un vrai service E2EE échouera au déchiffrement. Si le fichier s'ouvre quand même, le serveur détenait la clé depuis le début.

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