Zero-knowledge : explication simple du chiffrement à connaissance nulle
Par Simon Themiot - consultant cybersécurité freelance. Publié le 20 mai 2026.
En résumé
- Dans le périmètre du contenu E2E, le zero-knowledge signifie que le fournisseur ne reçoit pas la clé nécessaire pour lire les fichiers. Il peut néanmoins détenir des métadonnées, et la sécurité des terminaux comme du code client reste déterminante.
- C'est une propriété de l'architecture cryptographique, pas une simple promesse contractuelle : le serveur ne reçoit pas la clé E2E. Elle suppose toutefois un navigateur, un terminal et un JavaScript servis sans compromission.
- Très peu de services de transfert de fichiers sont réellement zero-knowledge. Beaucoup chiffrent les fichiers au repos avec des clés qu'ils gèrent eux-mêmes.
Sommaire
1. L'analogie du coffre-fort
Imaginez que vous voulez envoyer un document confidentiel à un collègue. Vous avez deux options :
Option A : La poste classique (= cloud standard)
Vous donnez votre document ouvert au facteur. Il le met dans une enveloppe fermée à clé. Il garde la clé. Il livre l'enveloppe à votre collègue. Le facteur promet qu'il n'ouvrira pas l'enveloppe. Mais il pourrait. Et si quelqu'un lui vole la clé, il pourrait aussi.
Option B : Le coffre-fort personnel (= zero-knowledge)
Vous mettez votre document dans un coffre-fort dont VOUS avez la combinaison. Vous donnez le coffre fermé au facteur. Il le livre. Vous communiquez la combinaison à votre collègue par un canal adapté. Le facteur ne peut pas ouvrir le coffre, et son vol en route ne suffit pas à révéler le document.
Le zero-knowledge, c'est l'option B appliquée au numérique. Le fournisseur transporte les données chiffrées sans disposer de la clé nécessaire pour lire leur contenu.
2. Définition technique
Un service est dit "zero-knowledge" (ou "à connaissance nulle") quand il remplit ces trois conditions :
- Les données sont chiffrées avant de quitter votre appareil (chiffrement côté client, dans le navigateur ou l'application).
- La clé de chiffrement n'est jamais envoyée au serveur du fournisseur, ni stockée par lui, sous quelque forme que ce soit.
- Le fournisseur ne peut pas reconstituer la clé, même s'il combine toutes les informations dont il dispose sur ses serveurs.
Dans ce contexte, "zero-knowledge" signifie que le serveur n'a pas connaissance du contenu en clair qu'il stocke. Il voit le texte chiffré ainsi que les métadonnées nécessaires au service, mais ne possède pas la clé permettant de retrouver le contenu.
3. Comment ça marche concrètement
Sur un service de transfert de fichiers zero-knowledge comme PrivCloud, voici ce qui se passe techniquement quand vous partagez un fichier :
- Génération de la clé : Votre navigateur génère une clé aléatoire de 256 bits (AES-256-GCM) en utilisant la
Web Crypto APIintégrée au navigateur. Cette clé est créée localement, sur votre machine. - Chiffrement local : Un Web Worker chiffre le fichier par enregistrements AES-256-GCM indépendants de 1 Mo. Le fichier en clair n'est jamais envoyé au serveur lorsque l'option E2E est activée.
- Envoi des données chiffrées : Les enregistrements sont regroupés dans des chunks de transport adaptatifs, puis téléversés. Le serveur voit le texte chiffré et les métadonnées nécessaires au partage, pas le contenu en clair.
- La clé va dans le fragment d'URL : La clé est placée après le
#dans l'URL de partage. Exemple :https://share.privcloud.fr/s/abc123#CLE_ICI. Par conception du protocole HTTP, le fragment (tout ce qui suit le#) n'est jamais transmis au serveur. Il reste dans le navigateur. - Partage du lien : Vous envoyez le lien complet (avec le fragment) à votre destinataire.
- Déchiffrement par le destinataire : Le navigateur du destinataire extrait la clé du fragment d'URL et déchiffre le flux localement. Le serveur n'a jamais reçu la clé ni le contenu en clair.
4. Ce qui se passe sans zero-knowledge
Sur WeTransfer, Dropbox, Google Drive, SwissTransfer et la plupart des services cloud, voici le flux réel :
- Votre fichier est envoyé en clair pour le service, tout en étant protégé par TLS pendant le transport.
- Le serveur reçoit le fichier et le chiffre avec une clé qu'il génère et gère.
- Quand le destinataire télécharge, le service autorise l'accès puis renvoie le contenu via TLS.
Dans ce modèle, l'infrastructure du fournisseur peut techniquement accéder au contenu. Le chiffrement au repos reste utile contre le vol, la perte ou la mauvaise mise au rebut des supports et contre certains accès au stockage ; il ne crée toutefois pas de barrière cryptographique contre le fournisseur, une réquisition valide ou une compromission disposant aussi du service de clés.
5. Comment savoir si un service est zero-knowledge
Voici les indices concrets pour identifier un vrai service zero-knowledge :
- Pour un partage E2E par lien, le fragment après
#peut transporter la clé : c'est le modèle utilisé par PrivCloud. L'absence de fragment n'est toutefois pas une preuve à elle seule : un autre service peut distribuer les clés via des comptes ou une application. - Le code source est ouvert : Vous pouvez inspecter le code JavaScript pour vérifier que le chiffrement se fait dans le navigateur avant l'envoi.
- Pour un partage par lien, perdre le fragment signifie perdre la clé : le fournisseur ne doit pas pouvoir la reconstituer. Les espaces Team peuvent, eux, redistribuer une clé chiffrée entre membres autorisés sans la révéler au serveur.
- La documentation technique est transparente : Le service publie un modèle de sécurité expliquant où et comment le chiffrement se produit.
- L'onglet "Network" apporte un indice : le contenu envoyé doit déjà être chiffré et ne pas exposer le fichier en clair. Un audit du code et du protocole reste nécessaire pour conclure.
6. FAQ
Zero-knowledge et chiffrement de bout en bout, c'est la même chose ?
Les notions se recouvrent, mais ne sont pas synonymes. Le chiffrement de bout en bout décrit le trajet protégé entre les clients autorisés. Le zero-knowledge décrit ce que le fournisseur peut connaître ou reconstituer. Une implémentation doit aussi préciser les métadonnées visibles, la distribution des clés et le modèle de confiance du code client.
Si je perds le lien, je perds le fichier ?
Oui. Pour un partage par lien, si le lien complet et sa clé sont perdus, le fournisseur ne peut pas recréer la clé. Les partages Team utilisent un autre mécanisme : les clés de fichiers sont enveloppées pour les membres autorisés, ce qui permet la collaboration et une rotation assistée sans donner les clés au serveur.
Le zero-knowledge ralentit-il le transfert ?
Il ajoute un coût CPU et des copies mémoire, surtout dans un navigateur. Sur une machine récente, le réseau reste souvent le facteur principal, mais ce n'est pas garanti : le matériel, le navigateur, la taille des chunks et l'écriture sur disque influencent aussi le débit. L'architecture sépare les enregistrements crypto de 1 Mo des chunks réseau adaptatifs pour limiter ce surcoût.
À lire aussi
Essayez le zero-knowledge par vous-même
PrivCloud est une application de partage temporaire, pas un cloud de stockage. Le chiffrement E2E AES-256-GCM est activable côté navigateur, avec une clé dans le fragment pour les partages par lien. Jusqu'à 2 Go sans compte et 3 Go avec le compte Free.
Dernière mise à jour : 14 juillet 2026.