Comment Transferify chiffre vos fichiers dans votre navigateur
Chaque fichier que vous envoyez avec Transferify est chiffré dans votre navigateur avant qu’un seul de ses octets quitte votre appareil. Le chiffrement est AES-256-GCM, exécuté par l’API Web Crypto intégrée à votre navigateur, et la clé est créée sur votre appareil pour chaque transfert. Les modes d’envoi ne diffèrent que sur un point : ce que devient cette clé ensuite.
Cet article explique le mécanisme pour celles et ceux qui veulent le vérifier : comment la clé est créée, comment un fichier est découpé et scellé, ce qui empêche de modifier un fichier stocké, et qui peut le déverrouiller dans chaque mode.
La clé est créée sur votre appareil
Quand vous lancez un transfert, votre navigateur demande à l’API Web Crypto une nouvelle clé AES aléatoire de 256 bits. Une même clé couvre tous les fichiers que vous envoyez ensemble. Les fichiers que vous ajoutez plus tard à un transfert hébergé reçoivent une nouvelle clé qui leur est propre.
La clé n’est dérivée ni de votre adresse e-mail, ni de votre compte, ni d’un mot de passe : rien de ce qui vous concerne ne peut servir à la deviner.
Les fichiers sont chiffrés en flux, par blocs
Votre navigateur lit chaque fichier en flux et le chiffre morceau par morceau. Un fichier bien plus volumineux que la mémoire de votre appareil se chiffre donc sans être chargé en entier.
- Les transferts hébergés utilisent des blocs de 8 Mio pour la plupart des fichiers.
- Les très gros fichiers hébergés utilisent un bloc plus grand, multiple entier de 8 Mio jusqu’à 256 Mio, afin que le fichier respecte toujours la limite du stockage, qui est de 10 000 parties par fichier.
- Les transferts pair à pair utilisent par défaut des blocs de 32 Kio, pour que chaque bloc chiffré tienne dans un seul message de canal de données, accepté par tous les pairs WebRTC.
Chaque bloc est scellé avec AES-256-GCM, qui le chiffre et lui ajoute un tag d’authentification de 16 octets. Si un seul bit du bloc change, le tag ne correspond plus et le déchiffrement refuse le bloc.
Chaque bloc est lié à sa place
Chiffrer les blocs un par un laisse une faille si rien ne lie chaque bloc à sa position : celui qui détient la copie stockée pourrait réordonner les blocs, supprimer le dernier ou glisser un bloc provenant d’un autre fichier. Deux mécanismes comblent cette faille.
Un nonce unique pour chaque bloc. AES-GCM a besoin d’un nonce, un nombre utilisé une seule fois, pour chaque bloc qu’il scelle. Le flux chiffré de chaque fichier commence par une valeur de 8 octets que votre navigateur choisit pour ce fichier et écrit dans l’en-tête du flux, et chaque bloc y ajoute son propre compteur de 4 octets. Au sein d’un fichier, deux blocs ne partagent jamais le même nonce. D’un fichier à l’autre, les valeurs de 8 octets sont aléatoires, ou dérivées d’un secret que détient votre navigateur : une répétition est donc infiniment improbable. Réutiliser un nonce avec la même clé est la seule chose qu’AES-GCM ne doit jamais faire.
Des données de position authentifiées. Chaque bloc est scellé avec une courte étiquette qui nomme le transfert, le fichier, l’indice du bloc et indique s’il s’agit du dernier bloc du fichier. Cette étiquette n’est pas stockée avec le bloc. Le navigateur du destinataire la reconstruit pour le fichier qu’il a demandé : un bloc ne se déchiffre donc qu’à l’endroit exact pour lequel il a été scellé.
| Si la copie stockée était… | Ce qui se passe au téléchargement |
|---|---|
| Modifiée, ne serait-ce que d’un bit | Ce bloc échoue à la vérification de son tag et le téléchargement s’arrête |
| Réordonnée | L’indice du bloc ne correspond pas, donc il échoue |
| Mélangée avec un bloc d’un autre fichier ou d’un autre transfert | Le fichier ou le transfert indiqué dans l’étiquette ne correspond pas, donc il échoue |
| Raccourcie | Le nouveau dernier bloc a été scellé comme « pas le dernier », donc il échoue |
| Prolongée par des données supplémentaires | Le vrai dernier bloc n’est plus le dernier, donc il échoue |
| Déclarée avec une autre taille | La taille déchiffrée est comparée à celle annoncée pour le téléchargement, donc il échoue |
Une vérification qui échoue arrête le téléchargement et supprime ce qui était en cours d’écriture : le destinataire obtient le fichier exact ou une erreur, jamais une copie silencieusement endommagée.
Les navigateurs des expéditeurs écrivent cette étiquette depuis octobre 2026. Les fichiers stockés avant cette date portent une étiquette antérieure, qui nomme seulement le transfert et l’indice du bloc, et les navigateurs des destinataires continuent de les lire.
Où va la clé : trois cas
Le fichier est chiffré de la même façon dans tous les cas. Ce qui change, c’est la manière dont le destinataire obtient la clé.
| Ce que nous comparons | Hébergé, par défaut | Hébergé, Zéro connaissance | Pair à pair |
|---|---|---|---|
| Comment la clé parvient au destinataire | Enveloppée et conservée par nous, déballée par notre service à l’ouverture du lien | Uniquement dans le lien, après le « # » | Uniquement dans le lien, après le « # » |
| Ce que nous stockons | Le fichier chiffré, et la clé enveloppée par une clé d’AWS Key Management Service | Le fichier chiffré seulement | Rien : le fichier n’est jamais stocké sur nos serveurs |
| Qui d’autre peut obtenir la clé | Notre service, par l’intermédiaire du service de gestion de clés | Personne | Personne |
| Transferify peut-il déchiffrer le fichier ? | Oui, sur le plan technique | Non | Non |
Hébergé, mode par défaut : la clé est enveloppée pour notre service
En mode par défaut, votre navigateur enveloppe la clé du fichier avant tout envoi. Il la chiffre avec RSA-OAEP (SHA-256) sous la moitié publique d’une paire de clés RSA de 3072 bits, dont la moitié privée est détenue dans AWS Key Management Service (KMS). La clé brute ne fait jamais partie d’une requête. Nous conservons la clé enveloppée avec l’enregistrement du fichier.
Quand un destinataire ouvre le lien, notre service vérifie d’abord que le lien n’a pas expiré et que le mot de passe est correct, si vous en avez défini un. Ce n’est qu’ensuite qu’il demande à KMS de déballer la clé, puis il la renvoie au navigateur du destinataire en HTTPS. C’est le navigateur du destinataire qui effectue le déchiffrement : notre service ne déchiffre pas le contenu des fichiers.
Dans ce mode, nous sommes donc techniquement capables de déchiffrer un fichier hébergé, et nous le disons. En échange, vous obtenez un lien court qui ne contient pas la clé, un lien que vous pouvez copier de nouveau depuis votre liste de transferts, et des liens que notre service peut envoyer par e-mail à vos destinataires. Un mot de passe défini dans ce mode est envoyé à notre service, stocké uniquement sous forme d’empreinte, et vérifié avant la remise de la clé.
Hébergé, mode Zéro connaissance : la clé reste dans le lien
Avec le mode Zéro connaissance, votre navigateur n’envoie aucun élément de clé. La clé est placée dans le lien de partage, après le signe « # ». Les navigateurs n’envoient pas cette partie d’une adresse quand ils demandent une page : nos serveurs ne la reçoivent donc jamais. La page du destinataire lit la clé dans le lien, la retire aussitôt de la barre d’adresse et déchiffre le téléchargement sur l’appareil du destinataire.
Si vous définissez aussi un mot de passe, le lien contient une clé enveloppée plutôt que la clé brute. Votre navigateur dérive du mot de passe une clé d’enveloppement avec PBKDF2 (SHA-256, 600 000 itérations, un sel aléatoire de 16 octets) et y scelle la clé du fichier. Le navigateur du destinataire refait la même opération avec le mot de passe qu’il saisit. Ni le mot de passe ni la clé brute ne nous parviennent, et un mauvais mot de passe échoue simplement à déballer la clé sur l’appareil du destinataire.
Comme la clé n’existe que dans le lien, notre service ne peut pas envoyer par e-mail un lien Zéro connaissance à vos destinataires : l’e-mail contiendrait un lien privé de sa clé. Vous partagez vous-même un lien Zéro connaissance, par un canal de confiance.
Pair à pair : chiffré deux fois
Un transfert pair à pair n’est jamais stocké sur nos serveurs. Votre navigateur crée tout de même une clé pour chaque transfert instantané, la place après le « # » dans le lien et scelle chaque bloc avec elle avant que le bloc entre dans la connexion WebRTC. Cette connexion est elle-même chiffrée avec DTLS. La raison de cette seconde couche est expliquée dans comment fonctionne un transfert pair à pair.
Ce que le chiffrement couvre, et ce qu’il ne couvre pas
Le chiffrement protège le contenu de vos fichiers. Ce que notre service traite pour faire fonctionner un transfert est détaillé dans notre Politique de confidentialité.
Deux autres limites méritent d’être énoncées sans détour :
- Un lien fonctionne pour quiconque le détient : ne le partagez donc que là où vous partageriez le fichier, et envoyez tout mot de passe par un autre canal.
- Le chiffrement dans le navigateur ne peut pas protéger un fichier sur un appareil déjà compromis, à l’une ou l’autre extrémité.
Essayez
Le chiffrement s’exécute à chaque transfert, sur tous les plans, sans rien à configurer. Envoyez un fichier maintenant : la clé est créée dans votre navigateur dès que vous commencez.
Questions fréquentes
Mes fichiers sont-ils chiffrés avant de quitter mon appareil ?
Oui. Chaque fichier hébergé et chaque fichier pair à pair est chiffré dans votre navigateur avec AES-256-GCM avant qu’un seul de ses octets soit envoyé, sur tous les plans. Il n’existe aucun moyen d’envoyer un fichier non chiffré.
Transferify peut-il déchiffrer mes fichiers ?
Dans le mode hébergé par défaut, oui, sur le plan technique. Nous conservons la clé du fichier enveloppée par une clé détenue dans AWS Key Management Service, et quand un destinataire ouvre le lien, notre service la déballe et la remet à son navigateur. C’est ce qui permet à un lien court de fonctionner sans contenir la clé. En mode Zéro connaissance, et pour les transferts pair à pair, la clé ne circule que dans la partie du lien située après le « # », que les navigateurs n’envoient pas aux serveurs : nous ne la recevons donc jamais.
Que se passe-t-il si quelqu’un modifie le fichier stocké ?
Le téléchargement échoue au lieu de produire un fichier endommagé. Chaque bloc porte un tag d’authentification lié à sa position, à son fichier et à son transfert : un fichier modifié, réordonné, mélangé avec un autre ou raccourci ne se déchiffre pas.