Comment fonctionne le chiffrement de bout en bout pour les fichiers

Le chiffrement de bout en bout pour le transfert de fichiers signifie que les octets quittant votre appareil sont chiffrés avec une clé qui ne touche jamais le serveur, et que seul votre destinataire prévu peut les déchiffrer. Le serveur stocke du texte chiffré, ne voit rien de significatif, et pourrait être compromis sans exposer le contenu de votre fichier. La recette cryptographique implique presque toujours un chiffrement symétrique comme AES-256-GCM ou ChaCha20-Poly1305 pour le fichier lui-même, enveloppé avec un échange de clés comme X25519 ECDH ou RSA-OAEP pour les données clés. L'ANSSI recommande explicitement ces algorithmes dans ses référentiels pour les échanges de données sensibles entre administrations et prestataires. Voici exactement comment cela fonctionne en pratique.

Le modèle de menace que le chiffrement de bout en bout défend réellement

Le chiffrement de bout en bout défend spécifiquement contre : le prestataire de transfert piraté, soumis à une injonction judiciaire ou malveillant ; les attaquants réseau interceptant le trafic TLS déchiffré au niveau des proxys ; les instantanés de sauvegarde du bucket de stockage tombant entre de mauvaises mains ; et l'accès interne par les employés du service. Il ne défend pas contre les logiciels malveillants sur l'appareil de l'expéditeur ou du destinataire, le phishing qui capture le lien de déchiffrement, ou les comptes destinataires compromis. Comprendre le modèle est essentiel, car "chiffré" est souvent utilisé abusivement pour signifier "TLS en transit plus AES au repos côté serveur", ce qui laisse le prestataire détenir les clés — une situation que le RGPD traite comme une mise en danger des données personnelles.

Le chiffrement symétrique pour le fichier

Les fichiers sont chiffrés avec un algorithme symétrique parce que la cryptographie à clé publique est trop lente pour les données volumineuses. Le choix moderne est AES-256-GCM, défini dans NIST SP 800-38D, qui assure à la fois la confidentialité et l'intégrité authentifiée en une seule passe. Une clé aléatoire de 256 bits et un nonce unique de 96 bits (jamais réutilisé avec la même clé) protègent chaque fichier. ChaCha20-Poly1305, défini dans RFC 8439 et RFC 8103, est une alternative souvent plus rapide sur les appareils sans accélération matérielle AES-NI, comme les processeurs ARM anciens. Les deux produisent un texte chiffré plus un tag d'authentification de 128 bits qui détecte toute altération.

Dérivation de clé à partir de mots de passe

Lorsque le chiffrement de bout en bout utilise un mot de passe, celui-ci n'est jamais directement la clé de chiffrement — ce serait trop faible face à la force brute. À la place, une fonction de dérivation de clé comme PBKDF2-HMAC-SHA256 avec 600 000 itérations ou plus (recommandation OWASP 2025), Argon2id avec m=19 Mio et t=2 (RFC 9106), ou scrypt (RFC 7914) étire le mot de passe en une clé robuste. Un sel aléatoire de 128 ou 256 bits empêche les attaques par table arc-en-ciel. La clé résultante chiffre le fichier. Le sel et le nombre d'itérations sont stockés avec le texte chiffré afin que le destinataire puisse reconstruire la clé en entrant le mot de passe.

Enveloppement par clé publique pour les transferts avec compte

Lorsque les destinataires ont des comptes avec des clés publiques publiées, la saisie d'un mot de passe n'est pas nécessaire. L'expéditeur génère une clé de chiffrement de fichier (FEK) aléatoire, chiffre le fichier avec AES-256-GCM en utilisant la FEK, puis chiffre la FEK vers la clé publique de chaque destinataire via X25519 ECDH selon RFC 7748 combiné avec HKDF-SHA256 selon RFC 5869 pour dériver une clé d'enveloppement, ou RSA-OAEP selon PKCS#1 v2.2 avec SHA-256. La FEK enveloppée se retrouve à côté du texte chiffré. Seul le détenteur de la clé privée du destinataire peut désenvelopper la FEK et déchiffrer le fichier. C'est le modèle Signal et WhatsApp pour les messages, adapté aux fichiers.

Le chiffrement de bout en bout basé sur les liens avec fragments d'URL

Une astuce ingénieuse dans les transferts via navigateur consiste à stocker la clé de déchiffrement dans le fragment d'URL (la partie après #). Les fragments ne sont jamais envoyés au serveur dans une requête HTTP. Un lien comme https://exemple.com/d/abc123#k=B9kZtR... transporte l'identifiant du fichier côté serveur et la clé côté client. Le navigateur télécharge le texte chiffré, lit le fragment en JavaScript et déchiffre localement. Le service ne voit jamais la clé. La mise en garde est que si le lien fuit quelque part — journaux, captures d'écran, aperçus d'applications de messagerie — la clé fuit avec lui.

Intégrité avec AEAD et hachages

Les modes d'Authenticated Encryption with Associated Data (AEAD) comme GCM et ChaCha20-Poly1305 empêchent l'altération. Un seul bit modifié dans le texte chiffré fait échouer la validation du tag d'authentification, et la fonction de déchiffrement renvoie une erreur plutôt qu'un texte en clair corrompu. En plus de l'AEAD, de nombreuses implémentations calculent un hash SHA-256 ou BLAKE3 du texte en clair comme entrée de manifeste afin que le destinataire puisse vérifier après déchiffrement que le fichier correspond à ce que l'expéditeur avait prévu. Cela est important pour les fichiers volumineux transférés en blocs, où une livraison partielle pourrait autrement réussir partiellement et échouer silencieusement sur une queue manquante.

Chiffrement par blocs pour les fichiers volumineux

Chiffrer un fichier de 10 Go en une seule opération AES-GCM nécessite de maintenir 10 Go d'état en mémoire, ce qui est impraticable dans les navigateurs. Les vraies implémentations divisent le fichier en blocs — typiquement de 1 Mo à 16 Mo chacun — et chiffrent chaque bloc indépendamment avec une sous-clé dérivée et un nonce basé sur un compteur. L'outil de chiffrement age, défini sur age-encryption.org, utilise des blocs de 64 Ko avec ChaCha20-Poly1305. Les limites de blocs permettent aussi aux navigateurs de diffuser le déchiffrement via l'API Streams, commençant le téléchargement sur disque avant l'arrivée du fichier complet, et prennent en charge les uploads reprenables lors des interruptions réseau conformément aux principes du protocole tus.io.

La sécurité de transport en complément du chiffrement de bout en bout

TLS 1.3 défini dans RFC 8446 reste indispensable en plus du chiffrement de bout en bout — non pas pour la confidentialité du contenu (celui-ci est déjà chiffré) mais pour la confidentialité des métadonnées : noms de fichiers, tailles et timing. TLS 1.3 avec échange de clés à confidentialité persistante comme X25519 signifie que même si la clé à long terme du serveur est compromise ultérieurement, les sessions enregistrées ne peuvent pas être déchiffrées. L'épinglage de certificat ou la précharge HSTS empêche les attaques de rétrogradation. Ensemble, le chiffrement de bout en bout plus TLS 1.3 protège à la fois le contenu des fichiers et le schéma opérationnel de qui envoie quoi à qui.

Pièges d'implémentation courants

Trois erreurs reviennent fréquemment. Premièrement, la réutilisation de nonces avec la même clé dans AES-GCM compromet catastrophiquement la confidentialité — utilisez toujours un nonce aléatoire ou un compteur qui ne se répète jamais. Deuxièmement, l'implémentation de la cryptographie avec des routines maison au lieu de bibliothèques auditées comme libsodium, l'API Web Crypto (SubtleCrypto) ou BoringSSL — les opérations en temps constant comptent pour prévenir les attaques par timing. Troisièmement, ne pas authentifier les métadonnées de fichier en même temps que le contenu — si l'identité de l'expéditeur, le nom de fichier ou la liste des destinataires n'est pas dans l'AAD (Associated Authenticated Data), un attaquant peut substituer des métadonnées sans être détecté. HexaTransfer traite ces problèmes en utilisant des primitives Web Crypto standard côté client avec des schémas éprouvés.

Vérifier qu'un service fait réellement du chiffrement de bout en bout

Lisez les affirmations marketing avec scepticisme. Le vrai chiffrement de bout en bout signifie que le prestataire ne peut pas déchiffrer les fichiers même s'il y est contraint par une décision judiciaire — ce qui est particulièrement pertinent dans un contexte RGPD où la protection des données personnelles est une obligation légale. Recherchez une documentation technique publiée décrivant les algorithmes exacts (AES-256-GCM, X25519, HKDF, nombre d'itérations PBKDF2), un code client open source auditable, et un modèle de menace qui reconnaît ce que le chiffrement de bout en bout défend et ne défend pas. Les services offrant une récupération de mot de passe côté serveur sur des fichiers chiffrés ne font pas du vrai chiffrement de bout en bout — ils détiennent les clés.

Essayez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.