Chiffrement de bout en bout vs Zero-Knowledge : quelle différence ?
Ces deux termes sont souvent utilisés de manière interchangeable, mais ils décrivent des modèles de sécurité fondamentalement différents. Comprendre la distinction pourrait changer la façon dont vous évaluez chaque application à laquelle vous confiez vos données.
Si vous vous êtes déjà intéressé aux outils axés sur la vie privée, vous avez probablement rencontré « chiffrement de bout en bout » et « zero-knowledge » comme arguments de vente. Beaucoup de gens — et même certaines entreprises — utilisent ces termes comme s'ils signifiaient la même chose. Ce n'est pas le cas, et la différence compte. Confondre les deux est l'un des moyens les plus fréquents pour les consommateurs de se retrouver à faire confiance à un service qui a finalement bien plus d'accès que son marketing ne le laisse entendre.
La version courte : le chiffrement de bout en bout porte sur qui peut lire les données pendant leur déplacement ; le zero-knowledge porte sur qui peut les lire au repos, à jamais, dans n'importe quel état. Un produit peut être E2EE sans être zero-knowledge. Un produit ne peut pas vraiment être zero-knowledge sans être aussi E2EE — mais c'est l'inverse qui piège la plupart des gens.
Le chiffrement de bout en bout (E2EE)
L'E2EE garantit que les données sont chiffrées sur l'appareil de l'expéditeur et uniquement déchiffrées sur l'appareil du destinataire. Aucun intermédiaire — ni le serveur, ni le FAI, ni le fournisseur de l'application — ne peut lire le contenu en transit. Les applications de messagerie comme Signal en sont l'exemple type : les clés sont négociées directement entre les participants, le serveur relaie du texte chiffré opaque, et la confidentialité persistante garantit que même la compromission d'une clé à long terme ne peut pas déchiffrer rétroactivement les sessions passées.
Cependant, l'E2EE seul ne garantit pas que le fournisseur ne peut pas accéder à vos données au repos. Si le fournisseur gère les clés de chiffrement, il peut toujours déchiffrer les données stockées sur ses serveurs. De nombreuses sauvegardes cloud « E2EE », y compris celles de certaines applications de messagerie grand public, tombent dans ce piège : les messages sont chiffrés de bout en bout entre téléphones mais téléversés vers une archive contrôlée par le serveur dans une forme que le fournisseur peut lire.
L'architecture Zero-Knowledge
Le zero-knowledge va plus loin. Dans un système zero-knowledge, le fournisseur n'a jamais accès à vos données en clair ni aux clés nécessaires pour les déchiffrer — ni en transit, ni au repos, jamais. Les clés de chiffrement sont dérivées d'un secret que vous seul connaissez, et toutes les opérations cryptographiques se font côté client. Le serveur est architecturalement incapable de lire vos données, même sous contrainte.
Le zero-knowledge ne concerne pas seulement le contenu des fichiers. Une implémentation robuste cache aussi les métadonnées dans toute la mesure du possible : noms de fichiers, structure de dossiers, relations de partage et étiquettes doivent être chiffrés, pas seulement les blobs qu'ils décrivent. Sinon, les métadonnées deviennent un canal latéral qui en révèle presque autant que les données elles-mêmes.
Pourquoi la distinction compte
Prenons un service de stockage cloud qui affiche l'E2EE. Vos fichiers sont chiffrés pendant l'envoi et le téléchargement. Mais si le service génère et stocke la clé de chiffrement en votre nom, une violation — ou une ordonnance judiciaire — pourrait quand même exposer vos données. Un service zero-knowledge élimine cette possibilité en garantissant que la clé n'existe que sous votre contrôle. L'équipe juridique d'un fournisseur zero-knowledge recevant une injonction peut répondre en toute vérité qu'elle ne peut pas se conformer, parce que l'architecture ne lui laisse rien à remettre.
Ce qu'il faut vérifier
Lorsque vous évaluez des outils pour des données sensibles, demandez-vous : qui détient les clés ? Si la réponse est quelqu'un d'autre que vous, ce n'est pas vraiment du zero-knowledge. Demandez ce qui se passe lors des procédures « mot de passe oublié » — si le fournisseur peut restaurer vos données via un lien e-mail, les clés doivent vivre quelque part qu'il contrôle. Demandez si les métadonnées sont chiffrées, pas seulement le contenu. Demandez si le client est open source pour que les réponses puissent être vérifiées.
Chez Keeplas, votre phrase de récupération de 24 mots ne quitte jamais votre appareil. Nous dérivons les clés de chiffrement localement avec Argon2id, enveloppons les clés partagées avec le post-quantique ML-KEM-768, et nos serveurs ne stockent que du texte chiffré qu'ils ne peuvent pas déchiffrer. C'est le standard que vos données méritent — et il est vérifiable dans le code source public.