Documentation
Comment ça marche
Cette page décrit ce que Crypto et Gotham font réellement. Chaque section commence par une explication en langage courant, puis donne le détail technique pour qui veut vérifier : protocoles, formats, décisions d’architecture. Le code du réseau Gotham est public et peut être relu ; celui de l’application ne l’est pas. Ce qui n’est pas encore en service est signalé comme tel.
01
Chiffrement de bout en bout
Seuls vous et la personne à qui vous écrivez pouvez lire vos messages. Ni nous, ni l’hébergeur d’un serveur, ni quelqu’un qui écoute le réseau ne voit le contenu. C’est le cas aujourd’hui, sur toutes les plateformes.
Dans le détail : chaque conversation démarre par un échange de clés X3DH, une méthode qui permet à deux appareils de fabriquer ensemble un secret commun sans jamais le faire circuler. Elle passe ensuite sous double cliquet (Double Ratchet) : la clé change à chaque message. Crypto ajoute la rotation des clés d’en-tête : à chaque étape, ce sont aussi les repères techniques de la trame qui changent, pas seulement la clé du contenu. Quelqu’un qui enregistre tout le trafic ne peut donc pas regrouper après coup les trames d’une même conversation.
Confidentialité persistante
Les clés de message servent une fois, puis sont détruites. Si votre appareil est saisi demain, il ne permet pas de déchiffrer le trafic capté hier.
Auto-réparation
Si un attaquant met la main sur une clé, l’échange suivant réinjecte de l’aléa neuf et referme la session. Pour continuer à lire, il doit rester présent en permanence, et cette présence continue se détecte.
Des identités vérifiables et révocables
Chaque paire de correspondants partage un numéro de sécurité : une suite de chiffres que vous comparez par un autre canal, de vive voix par exemple, pour être certain de parler à la bonne personne (c’est le modèle de Signal). Si la clé d’identité d’un contact change, l’application vous le montre et réinitialise la session. Jamais en silence.
Une clé d’identité peut être remplacée ou révoquée. Une clé révoquée met fin aux sessions en cours qui en dépendent. Elle n’est pas seulement notée quelque part comme invalide.
Post-quantique : le périmètre exact
Un futur ordinateur quantique pourrait casser une partie de la cryptographie utilisée aujourd’hui. Le socle intègre déjà une protection hybride, ML-KEM-768 combinée à X25519, sur la session applicative, celle qui protège vos messages. Depuis la version 2.3.0, cette couche ne peut plus être retirée en silence de la négociation : un intermédiaire qui l’enlèverait fait échouer l’échange au lieu de le déclasser. Elle ne couvre pas le transport : chaque saut entre relais repose sur la cryptographie classique, une protection par saut ne tenant pas dans le budget de 2048 octets d’un paquet. C’est une migration engagée, pas un produit « déjà post-quantique partout », et nous refusons de l’écrire autrement.
02
Anonymat de transport : le réseau Gotham
Le chiffrement protège ce que dit un message. Il ne cache ni son existence, ni sa taille, ni le fait que vous écriviez à telle personne à telle heure. Ces traces-là, les métadonnées, en disent souvent autant que le contenu. Gotham est le réseau que nous construisons pour les masquer : un réseau de mélange, où les messages rebondissent de relais en relais, aucun relais ne voyant jamais les deux bouts d’un même trajet.
Où nous en sommes aujourd’hui. Ce réseau ne route pas encore. Pour tracer une route, l’application exige un opérateur différent à chaque étape du trajet, donc au moins trois opérateurs indépendants les uns des autres : elle refuse, par construction, deux relais qu’elle ne peut pas prouver appartenir à des personnes différentes. Aujourd’hui, tous les relais sont exploités par une seule personne, l’auteur du projet. L’annuaire, lui, est déjà signé par trois autorités distinctes, dont deux doivent s’accorder pour admettre un relais — mais ces trois autorités appartiennent aussi à cette même personne. Le quorum protège contre la fuite d’une seule clé d’autorité, pas contre un unique opérateur qui déclare ses propres relais aux trois. Ce n’est pas une question de nombre de machines ni de plages d’adresses. En attendant, vos messages transitent par une boîte aux lettres, décrite à la section suivante : l’opérateur du relais peut donc voir quelles adresses IP échangent, et à quel moment. L’application l’indique telle quelle, sous la mention « Boîte aux lettres seule ». Le contenu, lui, reste chiffré de bout en bout dans tous les cas.
Ce qui suit décrit le protocole tel qu’il est implémenté, et la protection qu’il apportera le jour où assez de relais indépendants seront en service.
Routage en oignon (Sphinx)
Chaque message est emballé dans plusieurs couches de chiffrement, une par relais. Un relais n’ouvre que la sienne et n’apprend que l’étape suivante ; il sait en revanche à quelle étape du trajet il se trouve et combien d’étapes celui-ci compte, car le numéro de saut voyage en clair. Tous les paquets ont exactement la même taille, 2048 octets, avec un en-tête de 384 octets, et traversent jusqu’à cinq relais. Un observateur ne distingue ni la longueur réelle, ni le type, ni le destinataire d’un message. Chaque relais ré-emballe le paquet : ce qui entre et ce qui ressort ne se ressemblent pas.
Charge utile LIONESS
Le contenu est chiffré par blocs larges : modifier un seul bit détruit le bloc entier. Un relais ne peut donc pas glisser une marque discrète dans un paquet pour le reconnaître plus loin sur le trajet.
Délais et trafic de couverture (Loopix)
Chaque relais garde le paquet un temps aléatoire, tiré au sort à l’avance par l’expéditeur. En parallèle, l’application émet en permanence des messages factices, à un rythme lui aussi aléatoire. Un envoi réel part dans le même flux que ces leurres : sa temporalité ne le trahit pas.
Expéditeur scellé
Le premier relais du trajet ne sait pas quel compte est en train d’écrire. Prendre le contrôle de ce relais ne donne pas la liste des utilisateurs. Le numéro de saut lui apprend en revanche qu’il parle à un expéditeur et non à un autre relais : l’expéditeur scellé cache qui écrit, pas le fait que son voisin écrive.
Diversité de chemin imposée
L’application refuse deux étapes consécutives qui appartiennent au même opérateur ou au même bloc d’adresses IP (un préfixe /16 en IPv4, /48 en IPv6), et elle refuse en outre que l’entrée et la sortie relèvent du même opérateur. Un relais dont l’étiquette d’opérateur n’est pas prouvée ne compte jamais comme un opérateur différent. Un acteur qui contrôlerait un data center entier ne tiendrait donc jamais les deux extrémités d’un même chemin. C’est cette règle qui empêche aujourd’hui le réseau de router : elle réclame trois opérateurs indépendants, et il n’y en a qu’un. Nous préférons ne pas router du tout plutôt que router mal. Une réserve, que nous écrivons plutôt que de la taire : cette étiquette d’opérateur est aujourd’hui déclarée par le relais lui-même et signée telle quelle par l’autorité, et c’est l’une des deux failles encore ouvertes de notre registre.
L’anonymat d’un réseau de mélange dépend du nombre de relais indépendants réellement en service. C’est une propriété opérationnelle, qui se construit relais après relais, et non une case à cocher. Elle n’est pas encore acquise. Les limites exactes sont documentées dans le modèle de menace.
03
Boîtes aux lettres et relève
Quand la personne à qui vous écrivez n’est pas connectée, le message doit attendre quelque part. Il attend dans une boîte aux lettres : un serveur qui garde le message chiffré jusqu’à ce qu’elle vienne le chercher.
La boîte est désignée par un identifiant qui ne dit rien de son propriétaire et qui change à chaque époque de l’annuaire. Elle ne contient que des blocs chiffrés, tous de la même taille. L’hébergeur ne peut lire ni le contenu, ni le nom de l’expéditeur, ni celui du destinataire.
Chaque boîte est protégée par une preuve de possession : il faut démontrer qu’on détient la clé privée du destinataire pour y toucher. Sans cette clé, un tiers ne peut ni lire le courrier ni l’effacer à distance : une relève est destructrice, elle est donc réservée à celui qui détient la clé. Ce que l’hébergeur peut faire, en revanche : perdre ou détruire le courrier qu’il détient. Cela se voit comme une non-livraison, pas comme une fuite.
La relève est conçue pour passer par le réseau Gotham, au moyen de blocs de réponse à usage unique (SURB) : un chemin de retour préparé à l’avance par le destinataire, qui lui permet de récupérer son courrier sans livrer son adresse IP à l’hébergeur. Le mécanisme existe dans le protocole. Mais tant que le réseau ne route pas, la relève se fait en direct : l’hébergeur voit l’adresse IP qui vient chercher le courrier, et l’heure à laquelle elle le fait. C’est la limite la plus importante de la version actuelle.
Transport par rendez-vous
La plupart des connexions grand public (4G, 5G, box internet) ne peuvent pas recevoir de connexion entrante : l’opérateur partage une même adresse publique entre des milliers d’abonnés. Une machine dans cette situation peut tout de même héberger un relais, sans ouvrir le moindre port, en établissant elle-même la liaison vers un point de rendez-vous. C’est ce qui rend un réseau de relais bénévoles réellement déployable, au-delà des seules machines de data center. Le mécanisme est spécifié dans notre document technique B3.
04
Gouvernance du réseau
Un réseau d’anonymat ne vaut que ce que vaut sa liste de relais. Qui peut y glisser ses propres machines, ou vous faire croire qu’il n’en reste qu’une poignée, reprend d’une main ce que le reste du système protège de l’autre. Cette liste est donc traitée comme une cible d’attaque à part entière.
Annuaire signé, sans retour en arrière
La liste des relais est signée cryptographiquement (Ed25519) et la clé qui permet de vérifier cette signature est inscrite dans l’application. Une liste authentique mais périmée ne peut pas être rejouée pour rétrécir artificiellement le choix des routes. Depuis la version 2.4.1, cette clé peut être remplacée sans nouveau binaire : l’autorité publie la chaîne de ses successeurs, chaque maillon signé à la fois par l’ancienne clé et par la nouvelle. Aucune rotation n’a encore eu lieu en production.
Admission à plusieurs voix
Un relais doit être attesté par plusieurs autorités indépendantes — l’accord de deux autorités sur trois — avant de devenir utilisable, pour qu’aucune clé unique ne décide seule de la composition du réseau, pas même la nôtre. Le mécanisme tourne déjà en production sur trois hôtes distincts : la fuite ou la compromission d’une seule clé d’autorité ne suffit donc plus à forger le réseau. Mais les trois autorités appartiennent à la même personne aujourd’hui ; la protection contre un opérateur unique qui déclarerait ses propres relais aux trois n’existera qu’avec des autorités tenues par des tiers.
Inscription infalsifiable
Quand un relais s’inscrit, sa preuve de possession couvre l’intégralité de l’échange, pas seulement sa clé. Un attaquant placé sur le chemin réseau ne peut pas modifier au passage l’adresse ou l’opérateur déclarés. L’inscription elle-même est verrouillée par un jeton délivré par l’exploitant de l’autorité.
Surfaces exposées bornées
Chaque point d’entrée exposé sur le réseau dispose d’un cache anti-rejeu, d’une limite de débit et d’un plafond mémoire. Saturer un serveur pour le rendre indisponible est traité comme une classe d’attaque, pas comme un aléa d’exploitation.
05
Données au repos
Tout ce que l’application conserve sur votre machine, messages, contacts et clés, est stocké chiffré. Sans votre mot de passe, un disque récupéré ou une sauvegarde copiée n’apprennent rien.
La base locale est chiffrée par SQLCipher. Sa clé est dérivée de votre mot de passe par Argon2id, une fonction volontairement lente et gourmande en mémoire, qui rend l’essai systématique de mots de passe très coûteux, y compris avec du matériel dédié.
Le changement de mot de passe se fait d’un seul bloc : l’application prend un instantané de la base, la réécrit avec la nouvelle clé, puis détruit cet instantané une fois la nouvelle version validée. Cet instantané reste chiffré sous l’ancien mot de passe pendant l’opération — c’est ce qui permet de rattraper une coupure survenue en cours de route — et s’il ne peut pas être détruit, l’application l’écrit dans son journal au lieu de le passer sous silence.
06
Appels audio
La voix est chiffrée de bout en bout et ne passe jamais directement d’un appareil à l’autre : elle transite par un serveur relais. Votre correspondant ne voit donc pas votre adresse IP, et vous ne voyez pas la sienne.
Ce qu’il faut savoir. Ce relais est aujourd’hui opéré par nous. Son opérateur n’entend rien de la conversation, mais il voit les deux adresses IP et l’heure à laquelle vous vous êtes parlé. Les appels ne passent pas par le réseau Gotham et ne bénéficient donc pas de l’anonymat que celui-ci vise. Si le simple fait d’avoir appelé quelqu’un vous expose, tenez-en compte.
Côté technique, le moteur d’appel est natif, écrit en Rust, sans WebRTC de navigateur embarqué. Codec Opus, capture et restitution en temps réel, dissimulation des pertes de paquets.
Relais exclusif par défaut
Aucune connexion directe entre les deux appareils : aucun participant ne voit l’adresse IP de l’autre. Il n’existe pas de mode « optimisé » qui dégraderait discrètement ce point.
Configuration des relais signée
L’application reçoit la liste des relais média signée par l’autorité, et vérifie cette signature avant de s’en servir. Un attaquant placé sur le chemin réseau ne peut pas se désigner lui-même comme relais pour capter le flux.
Deux relais média par appel
Le flux est réparti sur deux serveurs relais distincts, afin qu’aucun opérateur ne voie les deux extrémités d’un même appel. La répartition fonctionne, mais les deux serveurs sont pour l’instant les nôtres : en pratique, c’est donc bien un seul opérateur qui voit les deux bouts. Cette séparation ne prendra tout son sens que le jour où un tiers indépendant en exploitera un.