Le chiffrement de bout en bout (end-to-end, ou E2E) est le mode de confidentialité le plus fort de Coffrify : vos fichiers sont chiffrés dans votre navigateur, avant tout envoi, et nos serveurs ne reçoivent jamais la clé qui permettrait de les lire. Cette page décrit précisément comment ce mécanisme fonctionne, où vit la clé, et ce que cela implique, y compris face à une demande judiciaire.
Le principe : chiffrer avant l'envoi
Quand vous ajoutez un fichier à un transfert E2E, votre navigateur génère une clé de chiffrement aléatoire et chiffre le contenu en AES-256-GCM, un standard symétrique reconnu et largement audité. Seuls des blocs chiffrés quittent ensuite votre appareil. Coffrify reçoit et stocke ces blocs, mais ne détient pas la clé : pour nos serveurs, ce ne sont que des données illisibles.
Où se trouve la clé : le fragment d'URL
La clé de déchiffrement est placée dans le fragment de l'URL de partage, c'est-à-dire la partie qui suit le caractère #. Un lien ressemble par exemple à https://coffrify.com/t/AbC123#k=..., où #k=... contient la clé.
La particularité technique est essentielle : le fragment (tout ce qui suit le `#`) n'est jamais envoyé au serveur par le navigateur. Il reste local au client. Concrètement, quand le destinataire ouvre le lien, son navigateur télécharge les blocs chiffrés, lit la clé depuis le fragment, puis déchiffre le contenu localement. À aucun moment la clé ne transite par Coffrify.
Ce que Coffrify stocke (et ne peut pas lire)
- Des blocs chiffrés, et uniquement cela, pour le contenu de vos transferts E2E.
- Aucune clé de déchiffrement : elle vit dans le fragment d'URL, côté client.
- Des métadonnées techniques nécessaires au service (taille, dates, plafonds de téléchargement), distinctes du contenu en clair.
Le mode « basique » (chiffrement côté serveur)
Certaines fonctionnalités supposent que le serveur puisse lire le contenu, par exemple la prévisualisation par le destinataire avant téléchargement. Pour ces cas, un mode basique (chiffrement côté serveur) est proposé en option. Le contenu reste chiffré au repos en AES-256-GCM, mais la clé est gérée côté plateforme, ce qui débloque l'aperçu et d'autres traitements. C'est un arbitrage entre commodité et confidentialité absolue : le E2E reste le réglage par défaut et le plus protecteur.
| Critère | Bout en bout (par défaut) | Basique (côté serveur) |
|---|---|---|
| Lieu du chiffrement | Navigateur (avant envoi) | Serveur |
| Détenteur de la clé | Vous (fragment d'URL) | Coffrify (hébergé en France) |
| Le serveur peut lire le contenu | Non | Oui, pour rendre le service |
| Prévisualisation destinataire | Indisponible | Disponible |
| Cas type | Confidentialité maximale | Confort de consultation |
La Réception (Inbox) : sealed-box X25519
La Réception, qui permet de recevoir des dépôts de tiers, repose sur un schéma de chiffrement asymétrique : une sealed-box X25519 (via libsodium). Le déposant chiffre son envoi à destination de votre clé publique, et vous seul, détenteur de la clé privée, pouvez le déchiffrer. Là encore, Coffrify transporte des données qu'il ne peut pas lire.
Conséquence : que se passe-t-il en cas de demande judiciaire ?
Le chiffrement de bout en bout a une conséquence directe et assumée : face à une réquisition judiciaire portant sur un transfert E2E, Coffrify ne peut remettre que des blocs chiffrés. La clé n'étant jamais en notre possession, nous sommes dans l'impossibilité technique de fournir le contenu en clair. Cette propriété, dite zero-knowledge, est au cœur de la promesse de confidentialité.
À retenir
- Chiffrement AES-256-GCM dans le navigateur, activé par défaut sur les transferts.
- La clé vit dans le fragment d'URL (après le
#) et n'est jamais transmise à nos serveurs. - Coffrify ne stocke que des blocs chiffrés ; un mode basique côté serveur est disponible en option pour la prévisualisation.
- La Réception utilise une sealed-box X25519 (libsodium).
- Données hébergées en France (Scaleway) par Evorax Technologies, conformes au RGPD.