Qui voit l'enveloppe : les métadonnées dans Signal, SimpleX, Session et XMPP comparées
Le chiffrement de bout en bout répond à une question — quelqu'un peut-il lire ce message pendant qu'il voyage — et ne dit rien de la question plus discrète qui compte tout autant : qui peut voir qu'un message a eu lieu. Les métadonnées de livraison — heures de connexion, adresses IP, identifiants, schémas de contacts — ne sont jamais chiffrées, car quelque chose doit rester lisible pour que le trafic soit routé.
Ce que couvrent les métadonnées
Le chiffrement du contenu cache ce qui est dit. Il ne cache pas qu'un appareil a contacté un service à un moment donné, depuis un réseau donné, en échangeant une charge utile d'une taille donnée. Le timing et le volume suffisent à esquisser qui parle à qui et quand ; c'est pourquoi les choix architecturaux de chaque messagerie en matière de métadonnées comptent autant que son chiffrement.Signal : sealed sender et rétention minimale
Signal réduit au minimum le stockage côté serveur et utilise depuis 2018 le sealed sender pour retirer l'identité de l'expéditeur de l'extérieur de chaque message ; la comparaison du projet : un courrier avec "a blank space where the 'from' address used to be", livrable en ne connaissant que la destination. Le même billet admet les limites : la résistance à la "traffic correlation via timing attacks and IP addresses" reste un chantier, et un appareil qui utilise Signal annonce malgré tout sa connexion à l'infrastructure de Signal. Ce que Signal conserve se documente moins par le marketing que par les divulgations juridiques. Sa page des demandes gouvernementales publie les transcriptions des réquisitions reçues ; en réponse à une subpoena d'un grand jury en 2016, l'entreprise a indiqué que les seules informations produisibles étaient la date de création du compte et la date de la dernière connexion de l'utilisateur. Des demandes traitées en 2021, puis après une nouvelle subpoena en mars 2026, répètent le même refrain : les données n'existent tout simplement pas sur les serveurs de Signal. Reste le résidu de tout design client-serveur : quand vous vous êtes connecté, et depuis où. Un identifiant structurel demeure : les comptes Signal sont créés à partir d'un numéro de téléphone, même si les pseudonymes gardent désormais ce numéro hors des listes de contacts d'autrui. Cela relie chaque compte à quelque chose du monde réel — ce qui compte quand le titulaire ne doit pas être relié à une personne.SimpleX : aucun identifiant d'utilisateur sur le réseau
SimpleX attaque le problème de l'identifiant de front. Au lieu de comptes, il relaie les messages via des files de messages par contact dont les adresses sont la seule chose qu'un serveur connaisse. Le projet affirme que "SimpleX Chat has no user identifiers visible to the network", profils, contacts et messages ne résidant que sur les appareils clients. Une conversation passe en général par deux relais différents, un par sens, si bien qu'aucun opérateur ne voit le trafic dans les deux directions. Le contrôle indépendant existe : un audit de code par Trail of Bits annoncé en novembre 2022 a relevé deux vulnérabilités de sévérité moyenne et deux de sévérité faible dans la bibliothèque cryptographique et réseau, aucune ne remettant en cause le modèle sans identifiants. Ce que voient les serveurs SimpleX, ce sont l'adresse de la file et la connexion qui y mène — c'est en grande partie pourquoi le projet a depuis investi dans le routage privé pour protéger les IP des expéditeurs vis-à-vis des opérateurs de relais. Comme pour tout design à relais, la marge dépend aussi de la taille du réseau : une file sur un serveur peu fréquenté se corrèle plus facilement qu'une file noyée dans un trafic dense.Session : onion requests sur son propre réseau
Session supprime numéro de téléphone et e-mail de la création de compte : un compte est un ID aléatoire fraîchement généré avec une phrase de récupération. Les messages traversent son réseau décentralisé en onion requests, superposés si bien que, selon le projet, "no single server ever knows a message's origin and destination". La livraison passe par des essaims de cinq à sept nœuds qui gardent les messages chiffrés jusqu'à leur retrait. La documentation va jusqu'à affirmer que cela rend "impossible for Session to track users' IP addresses" ; les affirmations absolues méritent la prudence, car un réseau plus petit exploité en propre repose sur l'intégrité de ses nœuds.XMPP avec OMEMO : du chiffrement sans promesses sur les métadonnées
XMPP est le cas fédéré. Le standard OMEMO (XEP-0384) apporte à XMPP le chiffrement type double ratchet de Signal avec gestion multi-appareils, traitant les serveurs comme non fiables pour le contenu. La spécification est honnête sur la frontière : elle ne protège pas contre les "metadata and traffic analysis". Sur un réseau fédéré, qui parle à qui est visible pour les serveurs hébergeant les comptes et pour tout ce qui se trouve sur le chemin de fédération entre eux. Choisir un fournisseur est donc une décision de métadonnées autant que de disponibilité : le chiffrement du contenu est standardisé, la protection des métadonnées dépend de l'opérateur.Ce qu'aucun ne supprime
La comparaison ne reste honnête que si elle se termine par ce que les quatre partagent :- Signal : le service voit les heures de connexion et les adresses IP, et l'inscription passe par un numéro de téléphone ; le sealed sender masque l'identité de l'expéditeur, et les divulgations publiées montrent que les données produites sont des dates de création et de dernière connexion.
- SimpleX : les relais voient les adresses des files et les connexions qui y mènent ; profils et messages restent sur les appareils, sans identifiant de compte au niveau du réseau.
- Session : IDs de compte aléatoires, routage en onion requests qui cache origine et destination aux nœuds individuels, messages chiffrés conservés temporairement dans des essaims de nœuds.
- XMPP avec OMEMO : contenu chiffré de bout en bout, mais serveurs et chemins de fédération voient qui communique avec qui et quand.
- Les quatre : un FAI ou un réseau local voit toujours qu'un appareil parle au service — ou à Tor, si tunnelisé — et la corrélation temporelle reste un problème ouvert partout.