Ce que le bout en bout laisse voir

Éditorial

Le chiffrement de bout en bout protège le contenu d'un message, pas le fait qu'il existe. Qui parle à qui, quand, combien et depuis où reste lisible, et cela suffit très souvent à savoir ce qu'on voulait savoir.

Mis à jour le 25 septembre 2026~27 min de lecture12 sections

papy cyber

→ Lire l’explication complète de la marmotte

Le cadenas et l’enveloppe

Le chiffrement de bout en bout est l’une des rares victoires nettes de la sécurité grand public depuis que la sécurité grand public existe, c’est-à-dire depuis peu, et de justesse. Quand une application affiche son petit cadenas en tête de conversation, la promesse est, pour une fois, tenue : le serveur qui transporte le message ne peut pas le lire.

C’est précisément parce que cette victoire est réelle qu’il faut regarder ce qu’elle ne couvre pas. On ne critique bien que ce qui marche ; le reste se critique tout seul.

Le cadenas protège ce qu’il y a dans l’enveloppe. Il ne dit rien de l’enveloppe. Or l’enveloppe est bavarde. Elle dit qui écrit, et à qui. Elle dit quand, à quelle fréquence, avec quelle régularité, à quelle heure de la nuit, et la nuit est rarement l’heure des bilans comptables. Elle dit combien pèse le message, s’il contient une image, un fichier, une voix. Elle dit, souvent, depuis quelle adresse réseau il est parti, donc à peu près d’où. Elle dit si l’on parle à deux ou en groupe, combien de membres compte ce groupe, qui l’a rejoint et quand. Rien de cela n’est chiffré par le protocole de bout en bout, pour l’excellente raison que le protocole de bout en bout n’a jamais prétendu le chiffrer. C’est nous qui l’avons cru, par un de ces glissements affectueux qui transforment une garantie précise en sentiment général.

La thèse de cet éditorial tient en une phrase, et la phrase est désagréable : dans une large part des situations où la confidentialité compte vraiment, l’enveloppe suffit. Nul besoin de lire un message pour savoir qu’une journaliste parle trois fois par semaine à un fonctionnaire d’un ministère depuis le début d’une enquête. Nul besoin d’écouter un appel pour savoir qu’une personne a contacté une commission de surendettement, puis un avocat, puis sa sœur, dans la même heure. Le contenu apporte les détails. La structure apporte le sens. Et le sens, contrairement aux détails, ne se chiffre pas.

Ce que « bout en bout » promet vraiment

Avant de reprocher à quelqu’un de n’avoir pas tenu parole, il est d’usage de relire ce qu’il a promis. La formule « de bout en bout » a un sens technique précis, qu’on gagnerait à apprendre avant de l’imprimer sur des panneaux publicitaires : les clés qui permettent de déchiffrer le contenu ne sont détenues que par les terminaux des participants. Le serveur relaie des blobs chiffrés qu’il ne sait pas ouvrir. C’est une garantie sur le contenu utile et sur l’identité des détenteurs de clés. Ce n’est pas une garantie sur le canal.

Les protocoles modernes ajoutent par-dessus des propriétés remarquables. La confidentialité persistante (forward secrecy) fait qu’une clé volée aujourd’hui ne permet pas de relire les messages d’hier. La sécurité après compromission (post-compromise security) fait qu’un attaquant qui a dérobé l’état d’un terminal en perd l’usage au bout de quelques échanges, parce que les clés se renouvellent sans lui demander son avis. Le détail de ces mécanismes, de la double rotation de clés jusqu’aux protocoles de groupe comme MLS, est exposé dans la page consacrée aux messageries et groupes chiffrés ; les briques d’échange de clés relèvent de Diffie-Hellman et des KEM. Tout cela est beau, solide, et porte sur un seul objet : les octets du message. Aucune de ces garanties ne porte sur le fait que le message existe.

Il y a une raison à cela, et ce n’est pas de la négligence. Un serveur de messagerie doit savoir à qui remettre un message ; c’est même, pour un serveur de messagerie, l’essentiel de sa vie intérieure. Il doit savoir si le destinataire est connecté, sinon lui garder le message au chaud. Il doit pouvoir réveiller un téléphone qui dort. Il doit pouvoir refuser les abus, freiner un compte qui envoie des milliers de messages à la minute, repérer une campagne de spam. Chacune de ces fonctions exige de voir une partie de l’enveloppe. Le routage d’un message est, par nature, une opération sur ses métadonnées : on n’a jamais vu un facteur distribuer le courrier les yeux bandés, sinon par accident.

Le chiffrement de bout en bout n’a donc pas oublié les métadonnées : il ne peut pas s’en occuper, parce qu’elles sont la matière même sur laquelle travaille l’infrastructure qui le transporte. Les protéger demande autre chose que de la cryptographie appliquée au contenu. Cela demande de reconstruire l’infrastructure, et c’est une autre discipline, avec un autre budget et beaucoup moins d’enthousiasme dans les comités de direction.

L’inventaire de l’enveloppe

Dressons la liste de ce qui reste visible, et surtout précisons à qui. La question « qu’est-ce qui fuit ? » n’a aucun sens sans la question « vers qui ? », de même que « on m’a vu » n’inquiète personne tant qu’on ne précise pas qui regardait. Au moins quatre observateurs voient des choses différentes.

Ce que voit l’opérateur du service

Dans une architecture de messagerie classique, le serveur central voit, pour chaque message : l’identifiant de l’émetteur (ou du moins du compte authentifié qui dépose le message), l’identifiant du destinataire, l’heure de dépôt et de remise, la taille du blob chiffré, et l’adresse IP de connexion des deux côtés. Il voit la présence : qui est en ligne, depuis quand, avec combien d’appareils. Il voit la composition des groupes, au moins sous forme d’identifiants, puisqu’il doit distribuer chaque message à chaque membre.

Il voit aussi, souvent, le carnet d’adresses, ou une forme qu’on a pris soin de rendre méconnaissable pour qu’il puisse la reconnaître. La découverte de contacts (savoir lesquels de vos contacts utilisent le même service) suppose de comparer votre carnet à l’annuaire des inscrits. Faite naïvement, la comparaison transmet tout votre carnet au serveur. Faite avec des condensats de numéros de téléphone, elle ne protège à peu près rien, parce que l’ensemble des numéros possibles est assez petit pour être parcouru en entier par une machine patiente. Hacher un numéro de téléphone, c’est lui mettre une moustache postiche : cela trompe ceux qui ne cherchaient pas.

Ce que voit le réseau

Entre votre terminal et le serveur, votre fournisseur d’accès, le Wi-Fi de l’hôtel ou l’opérateur mobile voient une connexion chiffrée par TLS vers une adresse IP appartenant au service de messagerie. Ils ne voient pas le destinataire. Mais ils voient quand vous émettez et recevez, combien. Ils voient aussi, dans la plupart des cas, le nom du service contacté, soit par la résolution DNS, soit par l’indication de nom de serveur transmise en clair au début de la négociation TLS, sauf lorsque l’extension qui chiffre cette indication est déployée des deux côtés, ce qu’il faut vérifier au cas par cas et qu’on ne vérifie jamais.

Un observateur qui surveille deux points à la fois (l’accès de l’émetteur et celui du destinataire) peut faire bien mieux : corréler les instants. Un message de telle taille part de A à 21 h 14 min 03 s ; un message de taille voisine arrive chez B à 21 h 14 min 04 s. Une fois, c’est une coïncidence. Trente fois, c’est une relation. Cette attaque ne touche ni au chiffrement ni au serveur : elle exploite le fait que le serveur relaie vite, ce qui est précisément ce qu’on lui demande et ce pour quoi on le félicite.

Ce que voient les intermédiaires techniques

Un téléphone ne garde pas une connexion ouverte avec chaque application ; il n’y survivrait pas jusqu’au déjeuner. Il délègue le réveil à un service de notification du système d’exploitation, opéré par le fabricant de la plateforme mobile. Le serveur de messagerie prévient ce service, qui prévient le téléphone. Même quand la notification est vide ou chiffrée, le service de notification apprend qu’un événement est survenu pour cette application, sur ce terminal, à cet instant. C’est un troisième acteur, que personne n’invite et que tout le monde nourrit, et qui dispose d’une vue horodatée de l’activité de toutes les applications installées. Le majordome sait à quelle heure on sonne chez chacun des locataires ; il n’ouvre pas le courrier, il n’en a pas besoin.

Ce que voit l’autre bout

Reste le destinataire, qui voit tout, et c’est le principe. Le chiffrement de bout en bout protège contre les intermédiaires, jamais contre le correspondant, qui demeure la faille la plus ancienne de la communication humaine et la moins corrigée. Une conversation impeccablement chiffrée en transit peut être capturée, transférée, sauvegardée en clair sur un appareil qui traîne sans code dans une poche. Le « bout » du bout en bout est un terminal, avec ses faiblesses, et la chaîne n’est jamais plus solide que la main qui tient le téléphone.

Pourquoi la structure suffit

On pourrait croire ces informations pauvres. Un identifiant, une heure, une taille : il faut vraiment n’avoir rien d’autre à faire pour s’y intéresser. Or, précisément, il existe des institutions entières qui n’ont rien d’autre à faire. Trois raisons rendent cette pauvreté redoutable.

La première est que les métadonnées sont structurées. Un contenu de message est du langage naturel : ambigu, allusif, truffé de fautes, coûteux à interpréter à grande échelle. Une métadonnée est une ligne dans une table : émetteur, destinataire, date, taille. Elle se trie, se filtre, se joint à d’autres tables, se dessine en graphe. Analyser dix millions de métadonnées est un problème de base de données ordinaire, de ceux qu’on confie au stagiaire. Analyser dix millions de messages est un problème de compréhension, de ceux qu’on ne confie à personne. Pour qui veut surveiller beaucoup de monde, la métadonnée est la donnée la plus rentable, précisément parce qu’elle est pauvre. Le pauvre a toujours été plus facile à ficher que le riche.

La deuxième est que le graphe révèle ce que les nœuds taisent. Une relation isolée ne dit presque rien. Le réseau des relations dit beaucoup : qui est au centre, qui fait le pont entre deux groupes qui ne se parlent pas, qui a changé d’habitudes la semaine où il s’est passé quelque chose. Les méthodes d’analyse de graphes (centralité, détection de communautés, rapprochement temporel) sont anciennes, bien outillées, et n’exigent aucun accès au contenu. Elles identifient des rôles : l’organisateur, le messager, la source.

La troisième est que le rythme parle. La fréquence d’un échange, son heure, sa régularité et ses ruptures sont des signaux d’une précision déroutante. Une conversation qui devient quotidienne, puis s’arrête net. Des messages entre 2 h et 4 h du matin, heure où l’on n’écrit ni à son banquier ni à son syndic. Une série d’appels brefs vers un même numéro, suivie d’un déplacement. Le contenu d’un message peut mentir ; son horodatage n’en a pas la présence d’esprit.

À cela s’ajoute un phénomène qui n’est pas propre à la messagerie : l’agrégation crée de l’information que les pièces ne contenaient pas. L’éditorial consacré à la conservation des journaux le formulait pour un corpus de sessions : deux fragments anodins, rapprochés, reconstituent un contexte qu’aucun des deux ne contenait. Les métadonnées de communication sont le cas d’école du mécanisme. Chaque ligne est banale ; le journal complet est une biographie, non autorisée, et remarquablement bien documentée.

Même la taille parle

Il existe une famille de fuites plus sournoise, qui ne concerne plus l’enveloppe mais le contenu chiffré lui-même, par sa silhouette. Un chiffrement moderne préserve, à quelques octets près, la longueur de ce qu’il chiffre.

Un message de trois octets n’est pas un rapport de dix pages ; on devine sans grand effort que c’est « ok ». Une image n’a pas la taille d’un texte. Les codecs de voix à débit variable produisent des paquets dont la taille dépend des sons prononcés : des travaux académiques ont montré que, sur un flux vocal chiffré mais non rembourré, on pouvait reconnaître des phrases connues à partir de la seule suite des tailles de paquets. Le même principe permet, sur du trafic web chiffré, d’identifier avec une bonne probabilité quelle page d’un site connu est consultée, à partir de la signature de tailles des ressources chargées.

Ce n’est pas une faille du chiffrement : c’est une propriété de ce qu’on lui confie. Un canal chiffré qui transmet des objets de tailles variables transmet aussi l’information portée par ces tailles. On a beau habiller quelqu’un d’une cape noire, on voit encore s’il est grand. Le seul remède est le rembourrage (padding), qui a un coût, et nous y viendrons, puisqu’on vient toujours au coût.

Les manières de réduire l’enveloppe

Si les métadonnées fuient parce que l’infrastructure en a besoin, les réduire consiste à bâtir une infrastructure qui en a moins besoin, ou qui les voit sans pouvoir les relier. Plusieurs familles d’approches existent. Aucune n’est complète, chacune se paie, et c’est justement ce qui les rend intéressantes : une solution gratuite à ce problème serait suspecte.

Minimiser ce que le serveur conserve

La plus simple, et la plus fragile, relève de la vertu : ne pas journaliser. Un service peut choisir de ne conserver ni la liste des contacts, ni l’historique des connexions, ni la composition des groupes au-delà de ce qu’exige la remise immédiate. Certains services revendiquent cette politique et, d’après ce qu’ils ont eux-mêmes publié, l’ont démontrée en répondant à des réquisitions judiciaires avec à peu près rien.

C’est une vraie protection contre une menace précise : la demande portant sur le passé. C’en est une beaucoup plus faible contre une menace qui s’installerait dans le présent. Une donnée que le serveur voit mais ne garde pas est une donnée qu’il pourrait garder demain, par décision de l’opérateur, sur injonction, ou parce qu’un attaquant a pris la machine et n’a pas lu la politique de confidentialité. La minimisation est une promesse sur une conduite, pas une propriété du système. Elle vaut ce que vaut la parole de celui qui la donne, et l’histoire de l’humanité est assez fournie en paroles données pour qu’on garde un peu de réserve.

Masquer l’émetteur au serveur

Une approche plus structurelle fait en sorte que le serveur ne sache pas qui envoie, tout en sachant à qui remettre. L’idée, déclinée sous plusieurs noms (l’une des variantes les plus connues s’appelle sealed sender), consiste à chiffrer l’identité de l’émetteur à l’intérieur du message, pour le seul destinataire, et à déposer le message sans s’authentifier comme émetteur. Le serveur voit « un message pour B », et non plus « un message de A pour B ».

C’est un progrès réel, et il faut en mesurer les bords. Le serveur voit toujours l’adresse IP de la connexion qui dépose le message. S’il voit la même adresse, au même instant, déposer un message pour B puis, quelques secondes plus tard, recevoir la réponse de B adressée à la même connexion, la corrélation temporelle refait une partie de ce que le masquage avait défait. L’émetteur est caché dans le protocole ; il reste visible dans le réseau.

Rendre la découverte de contacts aveugle

Pour le carnet d’adresses, plusieurs pistes coexistent. L’une s’appuie sur des enclaves matérielles : le calcul de l’intersection entre votre carnet et l’annuaire se fait dans une zone mémoire que même l’opérateur est censé ne pas pouvoir lire, et dont le code peut être attesté à distance. D’autres reposent sur des protocoles cryptographiques d’intersection privée d’ensembles, qui permettent de savoir ce qu’on a en commun sans révéler le reste, au prix d’un coût de calcul et de bande passante qui grimpe vite avec la taille de la foule.

La première déplace la confiance vers le fabricant du processeur, et vers une technologie dont l’histoire compte plusieurs attaques par canaux auxiliaires publiées : on change d’interlocuteur, pas de problème. La seconde est plus propre sur le papier et plus chère en pratique. Aucune n’est absurde. Aucune n’est gratuite.

Rembourrer et lisser

Contre les fuites de taille et de rythme, la réponse classique est l’uniformité : rembourrer chaque message jusqu’à une taille fixe (ou jusqu’à la prochaine d’une petite série de tailles), et émettre à rythme constant, en glissant du trafic de couverture (des messages factices indiscernables des vrais) lorsqu’on n’a rien à dire. Des messages qui ne disent rien, envoyés à heure fixe pour cacher ceux qui disent quelque chose : on reconnaîtra là une technique éprouvée de la conversation mondaine.

C’est redoutablement efficace et redoutablement coûteux. Le rembourrage multiplie le volume. Le rythme constant empêche le terminal de dormir, ce qui est rédhibitoire sur un téléphone dont la batterie a déjà du mal à finir la journée. Et surtout, cela ne protège que si tout le monde le fait : un utilisateur qui émet du trafic de couverture au milieu d’une population qui n’en émet pas se signale par cela même.

Mélanger les chemins

La famille la plus ambitieuse s’attaque à l’observateur réseau lui-même : faire passer les messages par plusieurs relais successifs, chacun ne connaissant que le précédent et le suivant, de sorte qu’aucun point unique ne voie à la fois l’émetteur et le destinataire.

Le routage en oignon à faible latence, dont le réseau Tor est l’exemple le plus connu, chiffre en couches et fait transiter le trafic par trois relais. Il protège bien contre un observateur local ou un relais malveillant isolé. Il est, de l’aveu même de ses concepteurs (qui ont sur ce point une honnêteté qu’on aimerait plus répandue), vulnérable à un adversaire capable d’observer les deux extrémités : la latence étant faible et le rythme préservé, la corrélation entre l’entrée et la sortie reste possible. C’est le prix de l’usage interactif, et il est affiché.

Les réseaux de mélange (mixnets) acceptent ce que le routage en oignon refuse : retarder les messages, les réordonner, les regrouper par lots, y mêler du trafic de couverture. Chaque relais attend d’avoir accumulé plusieurs messages, les brasse et les renvoie dans un ordre sans rapport avec l’ordre d’arrivée. Le lien temporel est cassé par construction. C’est la seule famille qui prétende résister à un observateur global, et elle le paie en latence (des secondes, parfois davantage) et en bande passante.

Plus la protection contre l’analyse de trafic est forte, plus le système est lent, lourd et désert. Et un système désert protège mal, parce que l’anonymat se mesure à la taille de la foule dans laquelle on se fond. Il est difficile de passer inaperçu dans une salle où l’on est seul, même en chuchotant.

Le coût, et qui le paie

On arrive au cœur du problème, et il n’est pas technique ; les vrais problèmes le sont rarement. Toutes les techniques qui réduisent les métadonnées dégradent quelque chose que l’utilisateur perçoit tout de suite, alors que le bénéfice qu’elles apportent est invisible et probabiliste.

La latence : un réseau de mélange ne permet pas une conversation vive, encore moins un appel. La batterie : le trafic de couverture tient le terminal éveillé. Le volume : le rembourrage mange le forfait. La fonctionnalité : la découverte automatique des contacts, les accusés de lecture, l’indicateur « est en train d’écrire », la synchronisation instantanée entre plusieurs appareils sont tous, à des degrés divers, des producteurs de métadonnées. Supprimer ces fonctions rend un service plus sûr et moins utilisé.

Voilà la dissymétrie qui explique l’état des choses. Le chiffrement du contenu est presque gratuit : quelques millisecondes de calcul, quelques octets d’en-tête, et aucun changement visible. C’est pour cela qu’il s’est généralisé, et non par une soudaine conversion morale de l’industrie. La protection des métadonnées coûte, et c’est l’utilisateur qui paie, chaque jour, pour un bénéfice qu’il ne verra jamais, puisqu’il prend la forme d’une surveillance qui n’a pas eu lieu.

S’y ajoute un effet plus pervers : l’effet de foule. Une messagerie qui protège bien les métadonnées mais que personne n’utilise protège mal ses utilisateurs, parce que le simple fait de l’utiliser devient une métadonnée. Qui installe un client de réseau de mélange se distingue de ceux qui ne l’installent pas. La protection des métadonnées est un bien collectif : elle n’est efficace qu’à grande échelle, et n’atteint la grande échelle que si elle est confortable. Ce cercle n’a, à ma connaissance, été brisé par personne, et ce n’est pas faute d’avoir vu passer des annonces de révolution.

Le meilleur argument contraire

Il serait facile de conclure que tout est perdu tant que l’enveloppe fuit. Ce serait injuste, et la complaisance dans le désastre est un luxe de chroniqueur. La position opposée a de vrais arguments ; exposons-les à leur meilleur.

Premier argument : la menace réelle de la plupart des gens n’est pas un observateur global. Pour l’immense majorité des utilisateurs, les adversaires plausibles sont un escroc, un ex-conjoint, un employeur indiscret, un cybercriminel qui a volé une base de données. Contre eux, le chiffrement de bout en bout fait l’essentiel du travail. L’opérateur ne peut pas vendre le contenu, la fuite de sa base ne révèle pas les conversations, le voisin sur le Wi-Fi public ne lit rien. Les métadonnées que voit l’opérateur ne sont accessibles qu’à l’opérateur et à ceux qui peuvent le contraindre ; pour qui ne craint ni l’un ni les autres, le risque résiduel est acceptable.

Deuxième argument : les métadonnées sont aussi une défense. La lutte contre le spam, le harcèlement de masse, la diffusion automatisée d’escroqueries s’appuie largement sur elles, précisément parce que le contenu est illisible. Un compte neuf qui écrit à dix mille inconnus en une heure se reconnaît sans lire un seul message. Un système qui ne voit rien ne peut rien filtrer. Réduire les métadonnées, c’est aussi désarmer la modération, et les premières victimes d’un service sans modération sont souvent ses utilisateurs les plus exposés. La vertu absolue a ceci de commun avec le vice qu’elle profite d’abord aux malins.

Troisième argument : la perfection est l’ennemie du déploiement. Si les concepteurs de messageries avaient attendu de savoir protéger les métadonnées avant de chiffrer le contenu, le contenu serait encore en clair. Le chiffrement de bout en bout a été déployé parce qu’on pouvait le déployer sans rien casser. Exiger davantage, tout de suite, c’est courir le risque de n’avoir rien.

Ces arguments sont justes, et je n’en conteste aucun. Mais ils répondent à une autre question. Ils disent que le chiffrement de bout en bout est suffisant pour certains modèles de menace. Ils ne disent pas qu’il protège la confidentialité des communications en général. Or c’est ainsi qu’il est présenté, et c’est ainsi qu’il est compris. Le reproche n’est pas qu’il protège mal ; c’est qu’on lui fait porter une promesse qu’il n’a jamais faite, comme ces parapluies vendus pour la tempête. Une personne dont le modèle de menace inclut un État, un employeur puissant ou un adversaire capable de contraindre l’opérateur a le droit de savoir que le cadenas ne la couvre pas contre ce qui l’inquiète le plus.

Ce que cela change en pratique

Que faire de ce constat quand on n’est ni concepteur de protocole ni opérateur de messagerie, mais simplement quelqu’un qui envoie des messages et voudrait, si possible, ne pas finir en graphe ? Quelques gestes, modestes, qui ont le mérite d’être honnêtes.

Choisir selon le modèle de menace, pas selon l’étiquette. Tous les services « chiffrés de bout en bout » ne se valent pas sur les métadonnées. La question pertinente est celle de l’encadré plus haut. Un service qui ne peut pas techniquement savoir qui écrit à qui vaut mieux qu’un service qui promet de ne pas le noter. On préfère le coffre sans clé au gardien qui jure de ne pas regarder.

Séparer les identités. Le numéro de téléphone comme identifiant est un choix d’ergonomie remarquable et une catastrophe pour les métadonnées : il relie le compte à un abonnement, souvent à une identité civile, et sert de clé de jointure avec toutes les autres bases qui utilisent le même numéro, c’est-à-dire à peu près toutes. Là où c’est possible, un identifiant dédié, sans lien avec le reste de la vie numérique, réduit ce qu’une fuite permet de relier.

Se méfier des fonctions qui bavardent. Accusés de lecture, statut de présence, « vu à », indicateur de frappe, aperçus de liens : chacune produit des métadonnées vers le serveur, et parfois vers le correspondant. Les désactiver ne rend pas un service anonyme ; cela retire des signaux inutiles.

Penser au réseau. Masquer l’adresse IP (par un relais, un VPN ou un tunnel) retire une information au serveur de messagerie, mais la confie à l’opérateur du relais. C’est un déplacement de confiance, pas une disparition du problème. On change de confident ; on ne cesse pas de se confier. Cela peut être pertinent ; ce n’est jamais gratuit.

Ne pas oublier les terminaux. Les métadonnées les plus riches dorment souvent en local : historique, carnet, journaux de notifications, sauvegardes. Un téléphone saisi ou compromis livre la structure complète des relations sans qu’on ait à interroger qui que ce soit. La sécurité du terminal reste, pour la plupart des gens, le maillon le plus directement actionnable, et le plus négligé.

Ce que je ne sais pas

Je ne sais pas mesurer la part des métadonnées effectivement exploitées. Tout le raisonnement de cet éditorial établit une capacité : ce qu’un observateur pourrait apprendre. Il ne dit rien de ce qu’il apprend réellement. Les usages effectifs des métadonnées par les opérateurs, les autorités ou les attaquants sont, par nature, mal documentés publiquement ; ceux qui savent n’écrivent pas, et ceux qui écrivent, dont je suis, ne savent pas. Je sais que la capacité existe. Je ne peux pas affirmer à quelle échelle elle sert.

Je ne sais pas si les réseaux de mélange sortiront un jour de la niche. Il existe des projets sérieux, sur des fondements académiques solides, qui tentent de rendre le mélange assez rapide pour les usages courants. Je n’ai aucun moyen de prédire s’ils atteindront la masse critique. L’histoire des technologies d’anonymat est un cimetière de systèmes excellents et vides, où les épitaphes sont très bien argumentées.

Je ne sais pas ce que deviendront les enclaves matérielles. Une partie des protections actuelles contre la fuite du carnet d’adresses repose sur elles. Si la confiance qu’on leur accorde s’effondre, une part des progrès récents s’effondre avec.

Je ne sais pas comment évoluera la régulation. Les débats sur l’accès légal aux communications chiffrées, en Europe comme ailleurs, portent en général sur le contenu. Ce qui relève de textes en cours de discussion doit être vérifié à la source, au moment où on le lit.

Ce qui reste

Le chiffrement de bout en bout est une victoire, et il faut la défendre. Mais il faut la nommer correctement : c’est une victoire sur le contenu, et le contenu n’est qu’une partie de ce que révèle une communication.

Trois choses me semblent acquises. Que les métadonnées ne sont pas un résidu mais une matière première : structurées, peu coûteuses à analyser, et révélatrices par agrégation bien au-delà de ce que chaque ligne laisse deviner. Que leur protection n’est pas un problème de cryptographie mais d’architecture, et qu’elle se paie en latence, en batterie, en fonctionnalités et en population, c’est-à-dire en tout ce qui fait qu’un service est adopté. Et que la question utile n’est pas « est-ce chiffré ? » mais « qui voit l’enveloppe ? », question à laquelle la réponse honnête n’est presque jamais « personne ».

Le cadenas est réel. L’enveloppe aussi. Tant qu’on les confond, on se croit à l’abri précisément là où l’on ne l’est pas, ce qui est la définition la plus exacte que je connaisse du confort.

Reste une remarque, qui prépare la suite. Dans l’inventaire de l’enveloppe, on a noté en passant que le nom du service contacté fuit souvent avant même que la connexion chiffrée ne s’établisse, par la résolution de nom. Cette fuite ne concerne pas seulement les messageries : elle concerne chaque site, chaque application, chaque mise à jour silencieuse. Elle passe par un protocole que presque personne ne regarde, et c’est le sujet de l’éditorial suivant.

🐝 Ce qui arrive si on s’en passe

Laisser l’enveloppe sans protection, c’est accepter qu’une fuite de la base de l’opérateur, qui ne livre aucune conversation, livre en revanche le graphe complet des relations de ses utilisateurs, horodaté, prêt à être joint à d’autres fichiers par le numéro de téléphone. Ce graphe ne se change pas comme un mot de passe : une relation révélée le reste, et aucune rotation de clé ne la rend secrète à nouveau. La ruche a verrouillé chaque alvéole et laissé à l’entrée le registre de qui rend visite à qui, et à quelle heure.

🦫 Explication de la marmotte 🍫

Le chiffrement de bout en bout fonctionne ainsi : seuls les appareils des personnes qui échangent possèdent les clés permettant de lire les messages. Le serveur de la messagerie transporte des données chiffrées qu’il ne peut pas ouvrir. Mais pour remettre un message, ce serveur doit savoir qui l’envoie, à qui, à quel moment, et pouvoir réveiller le téléphone du destinataire. Ces informations autour du message, appelées métadonnées, restent donc visibles. Plusieurs acteurs les voient : l’opérateur du service (expéditeur, destinataire, heure, taille, adresse réseau, composition des groupes, parfois le carnet d’adresses), le fournisseur d’accès à internet (heure et volume des échanges, nom du service contacté), le service de notification du téléphone (qu’un événement a eu lieu pour telle application), et bien sûr le destinataire. Ces données, simples et bien rangées, se trient et s’assemblent facilement ; en les reliant, on reconstruit qui parle à qui, qui occupe une place centrale et quand les habitudes changent. Même la taille des messages chiffrés trahit parfois leur nature. Des techniques réduisent ces fuites : ne pas conserver les informations, cacher l’expéditeur au serveur, comparer les carnets d’adresses sans les révéler, compléter les messages jusqu’à une taille fixe, envoyer des messages factices, ou faire passer le trafic par plusieurs relais qui mélangent les messages. Toutes coûtent en délai, en batterie ou en fonctionnalités, et ne protègent bien que si beaucoup de gens les utilisent.

Pages voisines

La citent

Ce que le bout en bout laisse voir

Elle cite

: les deux pages se citent l’une l’autre.

Ce que le bout en bout laisse voir

Le cadenas et l’enveloppe

Ce que « bout en bout » promet vraiment

L’inventaire de l’enveloppe

Ce que voit l’opérateur du service

Ce que voit le réseau

Ce que voient les intermédiaires techniques

Ce que voit l’autre bout

Pourquoi la structure suffit

Même la taille parle

Les manières de réduire l’enveloppe

Minimiser ce que le serveur conserve

Masquer l’émetteur au serveur

Rendre la découverte de contacts aveugle

Rembourrer et lisser

Mélanger les chemins

Le coût, et qui le paie

Le meilleur argument contraire

Ce que cela change en pratique

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines