Méthodes de chiffrement de transfert comparées en détail
Comparaison technique des méthodes de chiffrement pour le transfert de fichiers : AES-256, RSA, ChaCha20, bout en bout vs côté serveur.
Les services de transfert de fichiers utilisent cinq grandes approches de chiffrement en 2026 : TLS seul (données chiffrées en transit, mais texte en clair sur le serveur), AES-256 au repos côté serveur (le prestataire détient les clés), AES-256-GCM côté client via l'API Web Crypto (bout en bout, clé dans le fragment d'URL), chiffrement de flux XChaCha20-Poly1305 (nonce étendu, utilisé par libsodium et Tresorit), et chiffrement hybride OpenPGP (ECC Curve25519 + clés de session AES-256, utilisé par Proton). Le bon choix dépend du modèle de menace, des contraintes de performance et des exigences réglementaires. Cette comparaison explique ce que chaque méthode fait et là où chacune échoue.
Les cinq modèles de chiffrement
Modèle un : TLS 1.3 seul. Le fichier est chiffré pendant le transit réseau puis reste en clair sur le serveur. Exemples : FTP basique sur TLS (FTPS), tout envoi HTTP POST sans chiffrement au repos. Protège contre l'écoute réseau passive, ne protège contre rien d'autre.
Modèle deux : TLS + chiffrement au repos côté serveur. AES-256 chiffre le fichier stocké ; le prestataire détient la clé maître (souvent dans AWS KMS, GCP Cloud KMS ou équivalent). Exemples : WeTransfer, SwissTransfer, Dropbox. Protège contre le vol de stockage à froid, ne protège pas contre l'accès interne, les ordonnances judiciaires, ou la compromission de serveur actif.
Modèle trois : E2EE côté client avec clé symétrique. Le navigateur ou le client dérive une clé 256 bits, chiffre avec AES-256-GCM, et place la clé dans un fragment d'URL ou un canal hors bande. Exemples : HexaTransfer, descendants du protocole Firefox Send. Le serveur ne voit que du texte chiffré et ne peut pas déchiffrer sous aucune circonstance.
Modèle quatre : chiffrements de flux authentifiés. XChaCha20-Poly1305 utilise des nonces de 24 octets (contre 12 octets dans ChaCha20-Poly1305), rendant les collisions par birthday bound infaisables sur de très grands fichiers. Exemples : libsodium secretbox (Internxt), Tresorit Send. Choisi quand l'accélération matérielle AES-NI n'est pas universelle (anciens appareils Android, IoT) car ChaCha20 est rapide en logiciel pur.
Modèle cinq : hybride clé publique + symétrique. OpenPGP (RFC 9580, révision 2024) utilise ECC Curve25519 ou RSA-4096 pour chiffrer une clé de session AES-256 par fichier. Exemples : Proton Drive, chiffrement de fichiers GPG traditionnel. Permet la gestion asymétrique des clés ; aucun secret partagé nécessaire entre expéditeur et destinataire si vous avez sa clé publique.
AES-256 vs ChaCha20 : ce qui diffère vraiment
Les deux sont des chiffrements symétriques 256 bits. AES-256 est le standard NIST (FIPS 197) et bénéficie d'une accélération matérielle (AES-NI sur x86, extensions de cryptographie ARM sur mobile). Sur matériel moderne, AES-256-GCM tourne à 2 à 4 Go/s par cœur. ChaCha20-Poly1305 tourne à 1 à 2 Go/s par cœur en logiciel pur, plus rapide qu'AES sur matériel sans AES-NI. Pour un ordinateur de bureau chiffrant un fichier de 4 Go, les deux terminent en moins de deux secondes ; le réseau est le goulot d'étranglement. Cryptographiquement, les deux sont considérés comme équivalemment sûrs en 2026.
RSA est largement abandonné pour le transfert de fichiers
RSA-4096 chiffre 512 octets de texte en clair par opération. Utiliser RSA directement pour chiffrer un fichier de 1 Go est absurde ; vous le fragmenteriez en millions de blocs de 512 octets. Le schéma est toujours hybride : RSA enveloppe une clé de session AES-256 par fichier, AES chiffre le contenu. ECC Curve25519 a remplacé RSA dans la plupart des nouvelles conceptions car il est plus rapide, avec des clés plus petites (ECC 256 bits égale la sécurité de RSA 3072 bits), et résistant aux attaques temporelles. OpenPGP en 2024 recommande désormais Curve25519 (X25519 pour l'échange de clés) plutôt que RSA. Vous verrez encore RSA dans les déploiements SFTP legacy.
Pourquoi les clés dans les fragments d'URL comptent
HexaTransfer et la lignée du protocole Firefox Send placent la clé de chiffrement dans le fragment d'URL (la partie après le #). Les navigateurs sont spécifiés (RFC 3986) pour ne jamais transmettre les fragments dans la requête HTTP. Cela signifie que le serveur reçoit une requête comme GET /fichier/abc123 mais ne voit jamais le fragment contenant la clé. Quand l'utilisateur colle ou clique sur l'URL complète, le fragment reste dans la mémoire du navigateur et alimente le déchiffrement côté client. C'est la façon architecturalement élégante de livrer un lien E2EE partageable sans canal parallèle.
Bout en bout vs côté serveur : le test du modèle de menace
Le chiffrement côté serveur protège contre une chose : le vol physique du dispositif de stockage. Si le disque est volé, le chiffrement AES-256 au repos garde les données opaques jusqu'à ce que quelqu'un compromette le KMS. Le chiffrement bout en bout protège contre tout ce que le serveur pourrait faire : ordonnance judiciaire, accès interne, ransomware atteignant des données actives, ou coercition étatique. Si votre modèle de menace est « un disque est volé dans un datacenter », le chiffrement côté serveur convient. Si c'est « un gouvernement, un adversaire ou un concurrent contraint le service à remettre des données », seul l'E2EE vous protège.
Le chiffrement authentifié n'est pas optionnel
Un AES-CBC pur sans MAC permet des attaques de type padding oracle (BEAST, Lucky13) qui peuvent déchiffrer du texte chiffré avec des requêtes à texte chiffré choisi. Le transfert de fichiers moderne doit utiliser AEAD : AES-256-GCM (NIST SP 800-38D) ou ChaCha20-Poly1305 (RFC 8439). Le tag Poly1305 ou GCM authentifie le texte chiffré et toutes les données associées (taille du fichier, nonce, en-tête de nom de fichier). Si un bit se retourne en transit, le déchiffrement échoue bruyamment. Quiconque livre encore AES-CBC en 2026 sans enveloppe HMAC vit en 2010.
Dérivation de clé pour les transferts protégés par mot de passe
Quand un utilisateur saisit un mot de passe pour protéger un transfert, vous ne pouvez pas utiliser ce mot de passe directement comme clé AES. Il est peu entropique et vulnérable à la force brute. Dérivation moderne : PBKDF2-SHA-256 avec 600 000 itérations (recommandation OWASP 2023), scrypt avec N=2^17, ou Argon2id avec 19 MiB de mémoire et 2 itérations. HexaTransfer utilise PBKDF2 avec 600 000 itérations. Tresorit utilise Argon2id. Les deux résistent au craquage de mot de passe accéléré par GPU. Les prestataires qui utilisent encore PBKDF2 avec 10 000 itérations (directive de 2015) sont sous-sécurisés.
Tableau de comparaison
| Méthode | Confidentialité | Authentification | Serveur voit le texte en clair | Préoccupation quantique | |---|---|---|---|---| | TLS 1.3 seul | En transit | Oui (MAC dans la suite de chiffrement) | Oui | Échange de clés à risque | | AES-256 côté serveur | Au repos + en transit | Oui | Oui (a la clé) | Faible | | AES-256-GCM côté client | Chemin complet | Oui (tag GCM) | Non | Faible | | XChaCha20-Poly1305 | Chemin complet | Oui (tag Poly1305) | Non | Faible | | OpenPGP (Curve25519 + AES-256) | Chemin complet | Oui (MDC/OCB) | Non | Curve25519 à risque |
Considérations post-quantiques
L'algorithme de Shor menace Curve25519 et RSA une fois que de grands ordinateurs quantiques existeront. Les chiffrements symétriques (AES-256, ChaCha20) sont affaiblis mais pas cassés par l'algorithme de Grover ; les clés 256 bits conservent une robustesse post-quantique de 128 bits, toujours infaisable à forcer. Le NIST a standardisé ML-KEM (Kyber) en 2024 pour l'encapsulation de clés post-quantique. Signal a migré vers PQXDH en 2023. Les services de transfert de fichiers n'ont pas encore largement adopté le post-quantique, mais la fenêtre de risque (« collecter maintenant, déchiffrer plus tard ») signifie que les archives à longue rétention devraient utiliser un chiffrement symétrique 256 bits dès aujourd'hui.
Choisir une méthode
Transfert sensible ponctuel, courte rétention : AES-256-GCM côté client avec clés dans les fragments d'URL. HexaTransfer est l'implémentation de référence. Flux de travail réglementés continus : XChaCha20-Poly1305 avec journaux d'audit (Tresorit). Multi-destinataires avec gestion des clés : OpenPGP (Proton Drive, GPG). Grande distribution décentralisée : libsodium secretbox plus erasure coding (Internxt sur Storj). Volume élevé non sensible : TLS + au repos est acceptable.
Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier