Évaluez sans nous demander la permission.

Télécharger l’application

Au premier lancement, Windows et macOS afficheront un avertissement. C’est normal : nos fichiers d’installation ne sont pas encore signés auprès de Microsoft ni d’Apple. Sur Windows, cliquez sur « Informations complémentaires », puis « Exécuter quand même ». Sur macOS, le système annonce l’application comme « endommagée » : elle ne l’est pas, votre navigateur lui a simplement posé une étiquette de quarantaine. Le clic droit puis « Ouvrir » ne suffit pas dans ce cas. Glissez l’application dans Applications, puis retirez cette étiquette depuis le Terminal avec xattr -dr com.apple.quarantine /Applications/Crypto.app. Cette commande n’enlève rien d’autre sur votre machine. Sur Linux, il n’y a pas d’avertissement. Comme cet avertissement ne dit rien de l’authenticité du fichier, vérifiez plutôt son empreinte numérique : chaque version publiée donne l’empreinte attendue de chaque fichier et la commande qui permet de la comparer. Les mises à jour suivantes, elles, sont bien signées : l’application refuse toute mise à jour dont la signature n’est pas la nôtre.

Les composants du réseau (l’autorité qui tient l’annuaire, les relais, les boîtes aux lettres, les serveurs qui font transiter la voix des appels) s’installent depuis le dépôt public Gotham, sous licence libre AGPLv3 : n’importe qui peut lire ce code, le vérifier et l’héberger. L’application cliente et les fonctions destinées aux entreprises relèvent d’une licence commerciale distincte et leur code n’est pas public.

Nouveautés

Version courante : 2.4.1, publiée le 15 septembre 2026. Les trois dernières versions sont résumées ci-dessous, de la plus récente à la plus ancienne ; les numéros F-xx renvoient au registre interne des failles. L’application se met à jour seule : elle interroge GitHub toutes les 6 heures et n’installe que ce qui porte notre signature.

1. 2.4.1 · 15 septembre 2026

   Pas de migration de base, pas de rupture de compatibilité : cette version arrive par la mise à jour automatique et ne demande rien côté réseau.

   • Rotation des clés d’autorité (F-23). L’autorité peut désormais publier une chaîne de transitions où l’ancienne clé et la nouvelle signent le même énoncé. L’application avance en cliquet depuis une ancre qu’elle conserve : une fois la nouvelle clé adoptée, une ancienne clé qui aurait fui ne peut plus lui désigner de successeur. Ce que cela ne couvre pas : le tout premier contact, qui repose encore sur la clé compilée dans l’application. Aucune autorité ne sert de transition en production à ce jour.
   • Correctif rustls (RUSTSEC-2026-0285). La bibliothèque TLS passe de 0.23.39 à 0.23.45 dans l’application. Elle porte les poignées de main QUIC vers les relais et le HTTPS des mises à jour ; le chiffrement de lien du réseau (Noise XK) n’était pas concerné. Le binaire relais publié (v0.12.0) embarque encore l’ancienne version.
   • Jeton d’enrôlement rotatif. L’autorité accepte un fichier de jetons (--enroll-token-file, un jeton par ligne, tous valides), ce qui permet de changer le jeton sans étape simultanée sur toute la flotte ; elle refuse de démarrer si ce fichier est lisible par le groupe ou par tous. Ce jeton identifie la flotte, pas un opérateur : il n’apporte rien contre F-14.
   • Réception par rendez-vous réparée. Le tunnel introduit en 2.4.0 ne livrait rien : le test qui manquait l’a montré, le défaut est corrigé et le test reste. Vérifié en processus contre des relais locaux, pas contre la flotte vivante.

   Registre au 15 septembre 2026 : 56 failles corrigées, 13 réduites, 2 ouvertes. Les deux qui restent, F-14 et F-46, sont le même défaut vu de deux côtés : l’étiquette d’opérateur d’un relais est déclarée par le relais lui-même et rien ne la vérifie.

2. 2.4.0 · 15 septembre 2026

   Migration de base v35 → v36, irréversible : une base ouverte par 2.4.0 ne se rouvre plus avec 2.3.0. Sauvegardez le dossier de profil entier avant de mettre à jour.

   • Liens d’invitation valables 3 jours (F-53), contre 180 auparavant, comptés depuis leur création. Un lien plus ancien est refusé et sa clé est purgée.
   • Délai de mélange unique (F-68). Chaque mode d’anonymat émettait jusqu’ici son propre délai, lisible par le premier relais, qui pouvait ainsi trier le trafic par réglage. Les trois modes émettent désormais la même valeur, 500 ms par saut. Le débit de trafic de couverture, lui, distingue toujours les modes (en moyenne un paquet de couverture toutes les 15 s, 10 s ou 5 s).
   • Réception par rendez-vous (F-07, réduite). Un client derrière un NAT peut recevoir par le mixnet : il ouvre un tunnel vers un relais de rendez-vous, qui voit son adresse et son rythme, tandis que l’hôte de boîte ne voit qu’un bloc de réponse sans adresse IP. La propriété tombe si le relais de rendez-vous et l’hôte de boîte sont le même opérateur, ce qui est le cas du réseau actuel (F-14).
   • Adresses de boîte tournantes. L’adresse d’une boîte aux lettres est un hachage opaque de la clé publique du destinataire qui change à chaque époque de l’annuaire signé (calée sur son champ valid_after, jamais sur l’horloge locale). L’expéditeur dépose à l’époque courante ; le destinataire relève l’époque courante, la précédente et l’ancienne adresse permanente. Conséquence : un message déposé pour un contact resté en 2.3.0 et hors ligne ne lui parvient pas tant qu’il n’a pas mis à jour.
   • Édition, suppression et réactions dans les groupes (F-61). Chaque action est signée par son auteur sur un domaine distinct et vérifiée à la réception ; une suppression peut aussi venir d’un modérateur (permission MODERATE).

3. 2.3.0 · 13 septembre 2026

   Rupture de compatibilité. Un client 2.2.0 et un client 2.3.0 ne peuvent plus ouvrir de conversation, dans aucun sens ; les conversations déjà établies continuent. Migration de base v34 → v35, irréversible. Trois changements groupés exprès pour n’en faire qu’un :

   • En-tête Sphinx version 3 (F-01, réduite). Le code d’authentification de chaque saut ne couvrait qu’un segment de l’en-tête, celui du saut lui-même ; il couvre désormais ce segment et tous ceux qui suivent, ce qui ferme le canal de marquage entre un relais d’entrée et un relais de sortie complices pour les paquets v3. Résiduel : les relais acceptent encore l’en-tête v2 tant que le drapeau --strict-header-v3 n’est pas posé sur toute la flotte, et deux relais complices consécutifs gardent un canal que ce code ne peut pas fermer.
   • Lien d’invitation signé en entier (F-21, F-24, F-28). La signature par la clé d’identité couvre désormais tout le lien : clé éphémère, clé de routage Gotham, clé post-quantique ML-KEM et drapeau de rotation d’en-tête. Retirer le champ post-quantique invalide la signature, et le répondeur impose le schéma qu’il a annoncé : plus de déclassement post-quantique silencieux. Un lien sans signature est refusé, donc les liens partagés avant 2.3.0 cessent de fonctionner ; en regénérer un coûte un clic.
   • X3DH v2. La dérivation de clé de session change de domaine (Crypto_X3DH_v2) ; l’échange reste hybride X25519 + ML-KEM-768, suivi d’un Double Ratchet.
   • Relais. Le binaire relais publié (v0.12.0) porte l’en-tête v3, accepte encore v2 et gagne un cache de rejeu persistant (--replay-cache-path) qui survit aux redémarrages. Les relais doivent être à jour avant les clients : face à un relais ancien, un client 2.3.0 ne route rien.

Pour votre dossier d’évaluation

Il vous manque un document que vous ne trouvez pas ici, un dossier d’architecture ou des réponses à un questionnaire sécurité ? Écrivez-nous : un ingénieur vous répond.