Tox / qTox — dossier de preuves (situation au 13 octobre 2026)¶
Registre de preuves — Phase 2
Ce dossier est une pièce de recherche datée. La conclusion canonique est celle du rapport final 1.0. Les synthèses antérieures et renvois à la Phase 3 restent historiques. UNKNOWN reste UNKNOWN.
Périmètre à ne pas mélanger. Tox est un protocole/réseau P2P; toxcore est une bibliothèque cliente/protocolaire; qTox est un client desktop; les nœuds bootstrap sont des opérateurs distincts. Les propriétés réseau ci-dessous sont celles de toxcore/Tox; interface, sauvegarde et historique sont qTox. Les clients Android aTox/TRIfA sont des produits différents et ne sont pas assimilés à qTox.
Sources primaires principales : README et avertissement de sécurité c-toxcore, FAQ officielle Tox, liste officielle des clients et téléchargements, protocole de référence (spécification communautaire, ancienne et incomplète), manuel qTox, releases qTox du fork actif TokTok, changelog toxcore, advisory GHSA-42vg-9mg3-399f, issue KCI #426, code de chiffrement du profil toxencryptsave, étude forensique qTox (Meier, Choo, Le-Khac, 2022).
| # | Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|---|
| 1 | Architecture | Tox est P2P, avec DHT de découverte/routage, connexions UDP directes et relais TCP disponibles; des nœuds bootstrap publics servent d’entrée dans la DHT. | « serverless », distribué, sans autorité centrale. | La FAQ précise qu’un bootstrap public peut être utilisé et que les amis sont joints directement; la spécification note que le pair reçoit l’IP du contact. | « Sans serveur central » n’élimine ni bootstrap, ni observation par pairs, ni analyse de trafic; le coût est reporté vers les terminaux et opérateurs volontaires. | Quelle proportion réelle des installations utilise quel bootstrap, et quel routage selon client/NAT/proxy/version. |
| 2 | Protocole cryptographique | Toxcore s’appuie sur libsodium/NaCl; FAQ: Curve25519, XSalsa20, Poly1305. Le chiffrement du profil toxencryptsave utilise une dérivation scrypt-Salsa20/256 et un chiffrement authentifié NaCl/crypto_box selon le code. | La FAQ affirme E2EE avec forward secrecy pour les messages. | Le README c-toxcore reconnaît que le modèle de sécurité n’est pas complètement spécifié et que la bibliothèque n’a pas d’audit crypto externe formel. La référence du protocole laisse la description PFS comme TODO; issue KCI demeure ouverte. | Les primitives sont connues, mais cela ne suffit pas à prouver l’authentification, le ratchet, PFS, PCS ou déniabilité de chaque flux/version. | Propriétés formelles exactes du handshake et de PFS sur les clients actuels; protections PCS, déniabilité, transparence de clés et changements silencieux d’identité. |
| 3 | Création d’identité | La clé publique est l’adresse; Tox ID encode la clé publique, un champ anti-spam NoSpam et un checksum. Profil/clé sont générés et conservés localement par le client. | L’identité reste contrôlée par la clé privée locale et ne requiert pas de numéro/e-mail. | Manuel qTox et code toxcore décrivent le profil local; l’étude forensique 2022 retrouve compte et contacts à partir d’artefacts/mémoire. | L’ID public est pseudonyme mais stable et corrélable lorsqu’il est réutilisé ou publié. | RNG sur chaque plateforme/build, rotation de clé en usage réel, mécanisme cross-signing et migration d’identité. |
| 4 | Contact discovery | L’ajout se fait en échangeant manuellement le Tox ID; les lookups DHT utilisent des clés temporaires et des tunnels onion selon la FAQ. | La recherche d’un ami ne révélerait pas directement la paire de contacts aux nœuds DHT. | La FAQ documente ce mécanisme mais n’est ni audit ni mesure réseau; la spécification elle-même appelle à davantage de détails sur les données révélées. | Cela réduit le lien direct « ID durable ↔ requête DHT » mais ne protège pas l’IP contre un ami accepté. | Données et rétention de chaque nœud; résilience à Sybil/éclipse et efficacité de l’onion routing sur les builds actuels. |
| 5 | Métadonnées serveur | Il n’existe pas d’opérateur de stockage des messages; nœuds DHT/bootstrap voient une IP source pour leurs connexions et les données nécessaires au routage. | Pas de serveur central qui puisse établir le graphe social. | La documentation Tox reconnaît les bootstrap publics; la référence décrit clé temporaire/onion comme mitigation du lien social, pas une suppression de toute observation. | Plusieurs nœuds contrôlés ou l’observation du réseau peuvent relier événements et utilisateurs par temps/volumes, sans déchiffrer le corps. | Journaux effectivement conservés par nœuds bénévoles, champs observables par rôle et visibilité DHT actuelle. |
| 6 | IP utilisateur | Un nœud auquel le client se connecte reçoit l’adresse réseau source, sous réserve d’un proxy/Tor correctement configuré. | Tox peut fonctionner via proxy; la FAQ recommande Tor comme contournement à l’exposition directe. | La FAQ et la spécification avertissent que le protocole n’essaie pas de cacher l’IP lors des communications avec les amis. | Un SOCKS/TCP-only peut réduire l’exposition, mais ne transforme pas Tox en mixnet et peut créer d’autres fuites si mal configuré. | Comportement DNS, IPv6, WebRTC/ICE local, fallbacks et proxys par client/build; non mesuré dans ce rapport. |
| 7 | IP exposée au correspondant | La FAQ dit explicitement que l’IP est révélée à un contact lorsqu’on l’ajoute; les communications P2P directes rendent le chemin IP observable par les pairs. | Une connexion via proxy/Tor peut modifier ce que le pair voit. | La référence protocolaire précise que l’IP des amis est exposée et qu’ils peuvent la relier directement à l’ID. | Appels et transferts directs ont le même risque d’adresse réseau que la présence en ligne; un pair peut conserver/corréler cette IP. | Différence exacte par fallback relais TCP, groupe, système et paramètres de chaque client. |
| 8 | Messages | Messages chiffrés entre pairs; pas de store-and-forward central. qTox offre des « faux messages hors ligne » en conservant/réessayant localement les messages jusqu’au retour du correspondant. | Communication E2EE par défaut; pas de serveur d’historique. | Manuel qTox confirme que cette fonction est locale et liée à l’historique; l’advisory de sécurité démontre que le réseau traite aussi des paquets adversariaux non authentifiés dans certains sous-systèmes. | Message non livré lorsque l’émetteur et destinataire ne peuvent se croiser; sauvegarde locale d’un message sortant n’est pas une boîte serveur. | Fenêtre exacte de conservation/retry et sémantique de livraison pour versions récentes; PFS des messages effectivement observée. |
| 9 | Groupes | qTox annonce groupes/conférences; toxcore contient groupes et annonces DHT (GCA/NGC), avec évolutions et corrections fréquentes. | Group chat intégré au réseau Tox sans serveur central unique. | Le changelog 0.2.23 corrige notamment un débordement dans les annonces GCA; aucun audit crypto de groupe n’a été identifié. | Membres, clés, synchronisation et signaux de présence forment une surface distincte du chat 1:1; l’E2EE par membre ne prouve pas l’absence de métadonnées groupe. | Modèle exact des clés de groupe, accès des nœuds DHT, visibilité de membership/présence, rekey et confidentialité passée. |
| 10 | Appels | toxav prend en charge voix/vidéo; codecs publiés: Opus et VP8; transport géré par toxcore, généralement P2P. | Appels chiffrés via la même infrastructure cryptographique Tox. | Le changelog 2026 inclut des corrections de dépassement de tampon RTP/vidéo et de logique audio; aucun audit externe d’appel n’a été trouvé. | Le pair peut connaître l’IP et les horaires; codecs et protections de transport ne constituent pas à eux seuls une preuve d’E2EE de groupe ou de PFS média. | Clés et chiffrement exacts pour appels/conference, relay effectif, IP candidates, appels de groupe, risques de fuite audio et versions affectées. |
| 11 | Fichiers | qTox prend en charge les transferts de fichiers; dans Tox le transfert se fait entre clients, pas par un serveur d’archivage. | Transfert privé via Tox. | Manuel qTox confirme transfert et auto-acceptation configurable; l’étude qTox 2022 documente des artefacts de communication/fichiers, pas les propriétés crypto modernes. | Nom, taille, activité et temps sont visibles au pair; les fichiers remis peuvent contenir EXIF et contenu actif. | Chiffrement exact, résumés, reprise partielle, fragments sur disque et protection anti-malware par version. |
| 12 | Multi-device | qTox n’offre pas de synchronisation cloud/multi-appareils comparable à un compte serveur; il sait exporter/importer le profil. | Profil exportable entre clients compatibles. | Manuel décrit export et sauvegarde du fichier .tox; aucun service de synchronisation central n’est documenté. | Copier un même profil réplique la clé/identité, sans protocole fiable de gestion multi-device; concurrence peut causer désynchronisation ou exposition de la clé. | Compatibilité cross-client à chaque version et comportement quand plusieurs copies du même profil sont simultanément actives. |
| 13 | Push | qTox est desktop; pas de APNs/FCM requis par le client qTox standard. Les clients mobiles Tox sont séparés. | Pas de fournisseur push pour qTox desktop. | Les pages officielles listent aTox Android séparément; aucune fiche de confidentialité mobile unique ne peut être attribuée au protocole Tox. | Les apps mobiles pourraient dépendre de FCM ou d’une présence permanente, mais cela dépend entièrement du client. | Push, tokens, payloads, permissions et labels Play/App Store pour chaque client Android/iOS distinct; non transposable à qTox. |
| 14 | Stockage local | Profil et historique restent sur l’appareil; qTox documente SQLCipher pour l’historique et l’option mot de passe pour chiffrer le profil/l’historique. | Les données sont localement contrôlées; mot de passe disponible. | Code/documentation qTox décrivent SQLCipher et toxencryptsave; étude Meier et al. reconstruit données à partir d’image disque et mémoire sous Windows/Linux. | Sans mot de passe robuste, la protection au repos est nulle ou très réduite; une session déverrouillée expose texte et clés au processus. | Paramètres KDF/SQLCipher exacts du build livré, protection OS/hardware, copies WAL/cache, nettoyage des suppressions et chemin exact de chaque OS. |
| 15 | Sauvegardes | L’utilisateur peut exporter le profil .tox; l’historique peut être sauvegardé localement. | Pas de sauvegarde cloud imposée par le protocole. | Manuel qTox recommande une copie manuelle; toxencryptsave utilise une clé issue d’un mot de passe et avertit qu’un mot de passe oublié rend les données irrécupérables. | La copie de profil non chiffrée déplace la clé privée vers tout support où elle est déposée. | Sauvegardes OS automatiques, exclusions du dossier, cryptage des volumes et pratiques de l’utilisateur. |
| 16 | Analytics / SDK | Client desktop open source; aucune télémétrie réseau centralisée n’est inhérente au protocole. | La documentation met en avant absence d’autorité centrale; aucun dossier analytique produit exhaustif trouvé. | Dépôts publics et dépendances sont consultables; aucune inspection binaire dynamique indépendante n’a été effectuée ici. | Un protocole sans serveur n’empêche pas une distribution/client modifié d’inclure des analytics. | SDK, crash reporting, endpoints intégrés dans binaires distribués, diagnostics Windows/macOS et différence entre packages tiers. |
| 17 | Code source | qTox est GPL et c-toxcore est public; le dépôt qTox historique a été archivé en 2025, puis le fork actif du projet TokTok a publié v1.18.5 en juin 2026. | Le projet se décrit ouvert et communautaire. | Releases v1.18.5 et commit sont signés GPG/GitHub; c-toxcore avertit de l’absence d’audit externe crypto. | Le code public permet inspection, pas preuve que chaque binaire de chaque OS correspond au code. | Client exact du téléchargement officiel Tox, paramètres de build et différence des packages de distributions. |
| 18 | Reproductibilité des builds | CI et jobs de build publics existent; les releases contiennent archives/sommes/signatures. | Les utilisateurs peuvent compiler depuis les sources. | Aucun résultat attestant de reconstruction bit-à-bit du binaire qTox 1.18.5 n’a été trouvé. Une signature confirme l’origine selon une clé, pas la reproductibilité. | Signatures/release tags améliorent la traçabilité mais ne prouvent pas à eux seuls l’équivalence source-binaire. | Correspondance binaire exacte pour Windows/macOS/AppImage/Flatpak et dépendances système. |
| 19 | Supply chain | toxcore documente libsodium, cmp en sous-module, opus/libvpx pour A/V; qTox ajoute Qt, SQLCipher, FFmpeg/scaling et packaging par plateforme. | Build ouvert et releases signées. | Changelog montre correctifs upstream et audits manuels ponctuels; l’advisory GHSA prouve qu’une faille peut persister dans une bibliothèque réseau ancienne. | Surface C/C++ et dépendances compilées importante; les clients communautaires peuvent embarquer des versions différentes. | SBOM complet signé, provenance CI, dépendances vendored dans chaque binaire et procédure de réponse au compromis de mainteneur. |
| 20 | Infrastructure OSINT | Des nœuds publics sont listés pour bootstrap; des opérateurs séparés exploitent nœuds DHT/relays et l’éditeur de liste fournit un annuaire. | Le réseau n’a pas de serveur central. | Le site Tox expose publiquement liste de nœuds; la FAQ indique que des clients les utilisent pour bootstrap. | Les listes et domaines peuvent être bloqués/altérés même si le réseau DHT n’a pas de centre unique. | Cartographie passive actuelle par ASN/hébergeur, pays, indépendance opérationnelle et journaux des nœuds; non mesurée ici. |
| 21 | Juridiction | Pas d’opérateur central du service de messages identifié; bootstrap, hébergeur de l’annuaire et mainteneurs ont leurs propres juridictions. | Aucun propriétaire central du réseau. | Pas de société opérant tous les utilisateurs ni conditions de service centrales identifiées. | Une demande légale doit viser le bon opérateur ou les appareils; la décentralisation n’empêche pas une demande aux nœuds/FAI/store. | Entités des nœuds connus, demandes juridictionnelles à leurs opérateurs et juridiction de distribution des binaires. |
| 22 | Demandes policières | Aucun law-enforcement guide ou rapport de transparence Tox/qTox trouvé. | Pas de fournisseur central d’historique à qui demander les messages. | Aucun cas documenté de remise de messages par TokTok/Tox dans le corpus consulté; l’étude forensique montre la voie terminale, pas remise fournisseur. | Les opérateurs peuvent potentiellement produire leurs propres journaux; FAI peut détenir IP/temps; terminal contient les messages. | Données effectivement remises par opérateurs de nœuds ou stores dans une affaire identifiable. |
| 23 | Affaires judiciaires | Aucune décision publique trouvée montrant une donnée remise par Tox/qTox dans un cas réel. | — | Sources judiciaires consultées ne relient pas spécifiquement une remise toxcore à une procédure documentée. | L’absence de cas trouvé ne démontre ni absence de demandes ni invulnérabilité. | Recherches nationales non exhaustives et dossiers non publics. |
| 24 | Audits | README toxcore indique explicitement qu’aucun audit formel par un tiers crypto/cryptanalyse n’a été effectué. | Une « manual audit » par un contributeur a identifié la faille corrigée en 0.2.23. | Advisory public donne scénario, sévérité High et version corrigée; ce n’est pas un audit indépendant global. | Le correctif ciblé ne valide ni protocole cryptographique, ni clients, groupes, A/V et builds. | Durée, commit exact de toute revue manuelle, tests de retest indépendants; audit externe complet absent des sources publiques trouvées. |
| 25 | Vulnérabilités | GHSA-42vg-9mg3-399f (3 juin 2026, High): débordement de pile à distance dans GCA onion announce, versions ≥0.2.18; toxcore 0.2.23 corrige. CVE-2021-44847: overflow UDP historique, versions 0.1.9–0.1.11 / 0.2.0–0.2.12, corrigé 0.2.13. | Mainteneurs publient les correctifs et avertissements. | Advisory GitHub et bulletin officiel du projet documentent portée et version; aucun exploit en campagne observé n’est établi ici. | Gravité annoncée High pour un sous-système activé: risque surtout disponibilité/mémoire, sans preuve de RCE exploitable. | Prévalence des versions vulnérables en clients distribués, exploitation publique et impact exact selon compilation/configuration. |
| 26 | Recherche académique | Meier, Choo et Le-Khac (2022) décrivent la reconstruction forensique qTox; Tobias Buchberger a publié travail/thèse sur remplacement du handshake par Noise IK. | Projet Tox publie les pistes académiques et un prototype d’orientation Noise. | Étude forensique teste des machines virtuelles Windows/Linux et dumps mémoire; elle n’est pas une validation crypto. | Il existe une recherche ciblée, mais pas de preuve publiée d’une analyse formelle complète du protocole actuel. | Adoption effective du nouveau handshake Noise dans la release stable et évaluation indépendante de sa sécurité. |
| 27 | Incidents historiques | KCI handshake signalé en 2017; problème de VBR Opus avant c-toxcore 0.2.20; failles mémoire historiques 2021 et 2026 corrigées en versions ultérieures. | Le blog 2023 dit que la situation du KCI n’est pas exploitable avec le client courant sans implémenter un toxcore personnalisé; aucun PoC de production n’est revendiqué. | Issue KCI reste ouverte avec milestone v0.2.25 au 13-10-2026; RC c-toxcore .24 n’implique pas que le point est résolu. | KCI est un problème de modèle/handshake, distinct des dépassements mémoire; ne pas fusionner ni extrapoler la condition d’attaque. | Version cible d’intégration Noise, exploitabilité sur clients stock actuels et incidents non publiés. |
| 28 | Gouvernance / financement | TokTok maintient toxcore et le fork qTox; le repo qTox courant publie six fingerprints de maintainers actifs. | Organisation communautaire et contribution publique. | Activité des dépôts/releases et signatures observables; aucune société propriétaire ou rapport financier central n’est identifié. | Concentration probable sur un petit nombre de mainteneurs malgré la base de contributeurs historique. | Mainteneurs actifs en équivalent temps plein, fonds, contrôle des clés de signature et plan de succession. |
| 29 | Résistance à la censure | P2P et DHT évitent un serveur message unique; nœuds bootstrap, UDP/ports, domaines d’annuaire et protocoles peuvent être filtrés. | Réseau décentralisé. | FAQ recommande plusieurs nœuds bootstrap et cite proxy/Tor; pas de mesure pays ou DPI trouvée. | Résilience partielle: distribution du code, répertoire de nœuds et ports demeurent points de blocage. | Efficacité de Tor/SOCKS/TCP-only et couverture géographique sous censure DPI moderne. |
| 30 | Maintenance actuelle | qTox TokTok v1.18.5 (2-06-2026); toxcore stable v0.2.23 (3-06-2026), RC v0.2.24-rc.2 (30-09-2026). | Page officielle indique encore développement important et avertit que les logiciels peuvent contenir des vulnérabilités. | Releases signées et changelog récent incluent correctifs; la branche qTox originelle archivée en 2025 et remplacée par le fork TokTok actif. | Maintenance courante attestée, mais architecture crypto reste explicitement expérimentale/non auditée. | Cadence/compatibilité exacte des versions installées depuis chaque dépôt de distribution. |
Tox/qTox — audits, forensics et sécurité (détails)¶
- Audit crypto externe: aucun rapport ni organisme tiers pour c-toxcore/Tox trouvé. Le README de l’éditeur le nie explicitement. Pour l’événement 2026, c-toxcore attribue la découverte de GHSA-42vg-9mg3-399f à un audit manuel par le contributeur « iphy »; portée: fonction GCA onion announce de toxcore, pas durée, engagement contractuel, version/commit audité complet ou méthodologie formelle publiés. Finding: buffer overflow stack à distance, non authentifié, scénario exigeant une GCA initialisée et liste GCA/DHT assez remplie; risque déclaré High, crash DoS le plus probable, corruption mémoire adjacente possible; fix 0.2.23, aucun retest externe publié. Ce n’est pas un audit complet du protocole.
- KCI: issue #426 ouverte depuis 2017, priorité P1/security, milestone v0.2.25. Elle décrit l’usurpation d’un contact par un attaquant qui a compromis la clé privée statique de la victime et peut construire le handshake/réseau nécessaire. Le billet du projet (2023) nuance l’exploitation stock: l’attaque discutée requiert de personnaliser toxcore; cela ne clôt pas le problème de conception et n’est pas une preuve de fix. Au 13-10-2026, issue toujours ouverte, aucun retest indépendant identifié.
- Autres advisories: CVE-2021-44847 affectait le chemin UDP de versions toxcore 0.1.9–0.1.11 et 0.2.0–0.2.12; le projet publiait le correctif 0.2.13 et une mitigation TCP-only. Historique, ne décrit pas une version actuelle. Le changelog antérieur à 0.2.20 mentionne aussi le risque de transcription lié à VBR Opus.
- Forensics qTox: Meier, Choo et Le-Khac (2022), Windows et Linux en VM, images système + dumps mémoire, analyse du code et de la base SQLite/SQLCipher chiffrée; étude dit que les outils forensiques standards ne détectaient pas/reconstruisaient pas correctement qTox et fournit une approche pour retrouver comptes, amis et conversations. Le résumé public ne précise pas la version exacte du client ni une version Cellebrite/GrayKey/Magnet; le chapitre complet est accessible sous DOI, pas de test 2026. Les données accessibles par mot de passe/session mémoire ne doivent pas être confondues avec une extraction sans clé.
- Forensics commerciaux: aucun résultat public daté reliant précisément Cellebrite/GrayKey/Magnet + modèle/OS/build + qTox version n’a été trouvé. L’article académique n’est pas une validation d’un parseur commercial actuel.
Tox/qTox — matrice métadonnées¶
| Métadonnée | Fournisseur / nœud | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ aux nœuds DHT/bootstrap/relays auxquels on se connecte; journaux inconnus | CONFIRMÉ pour amis ajoutés, direct; VPN/proxy/Tor peuvent substituer l’IP | CONFIRMÉ adresse/temps/volume des connexions réseau | POSSIBLE pour téléchargement/compte store; qTox n’utilise pas de push mobile standard | POSSIBLE via FAI, nœud ou terminal; remise spécifique inconnue |
| Téléphone | NON ACCESSIBLE PAR DESIGN du protocole; pas de compte numéro | POSSIBLE si divulgué séparément | POSSIBLE via données d’abonnement/corrélation, pas par Tox ID | POSSIBLE au compte store/opérateur, pas à qTox de manière inhérente | POSSIBLE chez opérateur/appareil; aucun cas qTox documenté |
| NON ACCESSIBLE PAR DESIGN pour Tox ID; POSSIBLE pour services de distribution/support | POSSIBLE si communiqué dans la conversation | NON ACCESSIBLE PAR DESIGN via Tox seul | POSSIBLE au store/distribution | POSSIBLE par store, support ou terminal; pas de disclosure tox documentée | |
| Identifiant | POSSIBLE bootstrap reçoit clé temporaire; pas de compte central stable connu | CONFIRMÉ Tox ID/public key et nom choisi | POSSIBLE par corrélation de flux | POSSIBLE par identité de store/app installée | POSSIBLE chez contacts, store, nœuds ou acquisition terminal |
| Graphe social | PROBABLE limité par onion lookup/keys temporaires; journaux des nœuds INCONNUS | CONFIRMÉ pour contacts/groupes locaux et ceux avec qui l’on communique | POSSIBLE timing/volume multi-flux | POSSIBLE via identité store/backup, non démontré pour qTox | POSSIBLE par contacts, devices, ISP/nœuds corrélés; remise réelle inconnue |
| Timestamps | POSSIBLE aux nœuds qui voient un flux; conservation inconnue | CONFIRMÉ dans historiques/états en ligne selon client | CONFIRMÉ pour sessions/flux | POSSIBLE via distribution/app activity/store | POSSIBLE si logs détenus; aucun cas Tox trouvé |
| Volumes | POSSIBLE à chaque nœud/relay | CONFIRMÉ par trafic reçu et fichiers/calls | CONFIRMÉ octets/durée | POSSIBLE selon télémétrie OS/store, non établi qTox | POSSIBLE via FAI/nœuds ou endpoint |
| Groupes | POSSIBLE via DHT/annonces selon protocole, contenu exact INCONNU | CONFIRMÉ membership, messages et clés visibles aux pairs du groupe | POSSIBLE par timing/volumes | POSSIBLE pour clients mobiles séparés | POSSIBLE via pairs, DHT et appareil; data remise inconnue |
| Appareils | INCONNU côté nœuds; aucune gestion de compte | POSSIBLE par présence/duplicata d’identité et messages, selon client | POSSIBLE par motifs de connexion | CONFIRMÉ au niveau de l’écosystème store si app installée | POSSIBLE via saisie/extraction et données compte stores |
| Push tokens | NON ACCESSIBLE PAR DESIGN pour qTox desktop; clients mobiles hors périmètre | NON ACCESSIBLE PAR DESIGN | NON ACCESSIBLE PAR DESIGN sans accès terminal | INCONNU pour aTox/TRIfA séparés; non imputable à qTox | POSSIBLE auprès du push provider du client mobile concerné, aucun cas établi |
Tox/qTox — TM1 à TM15 (provisoire, justification par la matrice ci-dessus)¶
| TM | Résistance | Justification |
|---|---|---|
| TM1 fournisseur curieux | 🟡 | Pas de stockage central; les nœuds auxquels le client se connecte peuvent voir IP/temps/volume. |
| TM2 fournisseur compromis | 🟡 | Pas de backend unique de messages, mais nœuds bootstrap/annonces et distribution peuvent être compromis ou surveillés. |
| TM3 fournisseur malveillant | 🟠 | La clé publique authentifie un pair, mais absence d’audit externe, issue KCI ouverte et distribution/client sont des surfaces. |
| TM4 ISP / Wi-Fi | 🟠 | Connexions IP directes/DHT et horaires visibles; proxy/Tor peuvent réduire, pas prouver une protection complète. |
| TM5 observateur passif puissant | 🟠 | Routage P2P, flux directs et horaires corrélables; pas de mixnet ni padding global documenté. |
| TM6 adversaire global passif | 🔴 | Aucun mécanisme Tox connu ne vise la résistance à une corrélation globale. |
| TM7 contact malveillant | 🔴 | Un ami reçoit l’IP selon la FAQ; il peut enregistrer messages, appels, fichiers et liens d’identité. |
| TM8 doxxer OSINT | 🟡 | Pas de téléphone requis, mais Tox ID stable et réutilisation du pseudo/IP permettent corrélation. |
| TM9 demande judiciaire classique | 🟡 | Pas de fournisseur central pour les messages; FAI/nœud/store/terminal peuvent toutefois avoir des données. |
| TM10 police sophistiquée | 🟠 | Combiner ISP, nœuds, correspondant et endpoint peut relier IP et compte; aucun cas de remise fournisseur identifié. |
| TM11 appareil verrouillé saisi | 🟡 | Profil/historique peuvent être protégés par mot de passe et SQLCipher; sans mot de passe ou avec copies non chiffrées, exposition. |
| TM12 appareil déverrouillé | 🔴 | Données sont ouvertes au client et mémoire; étude forensique qTox reconstruit des artefacts depuis disque/mémoire. |
| TM13 spyware ciblé | 🔴 | Terminal compromis lit contenu, clé, microphone/caméra et activité avant chiffrement. |
| TM14 supply-chain compromise | 🟡 | Code ouvert, releases signées et CI, mais pas de rebuild exact indépendant; dépendances compilées et petit noyau de mainteneurs. |
| TM15 censure étatique | 🟡 | DHT distribué mais bootstrap/domains, UDP, ports, magasins et distribution peuvent être filtrés. |
Contradictions/tests Tox : « aucun serveur » ne signifie pas absence de nœud d’entrée et d’opérateur; « IP cachée dans la DHT » ne couvre pas l’IP révélée aux amis; la revendication PFS de FAQ n’est pas vérifiée par le protocole de référence, qui marque ce point TODO, et coexiste avec un handshake KCI encore ouvert. Expériences nécessaires : capture réseau qTox 1.18.5 (bootstrap/direct/TCP-relay/proxy/Tor, IPv4/IPv6/DNS); test en comptes isolés d’exposition IP selon l’ajout, appels, fichiers et groupes; reconstruire binaire d’archive et comparer; inspection permissions/SDK de chaque client mobile séparément; analyse mémoire et DB sous sessions verrouillée/déverrouillée avec version actuelle; vérifier l’intégration réelle de la correction GCA .23 et du handshake prévu pour .25.