D’appareil à appareil.
Un trajet expliqué.

Appareil à appareil, lorsque le réseau le permet.

Le trajet direct visé fait circuler les données de la conversation entre les appareils, sans serveur applicatif intermédiaire pour porter ce flux. Il réduit ainsi le rôle d’un relais dans le chemin du contenu.

Pour qu’un échange en temps réel fonctionne, les deux appareils doivent pouvoir se joindre. Le réseau Wi-Fi, l’opérateur mobile, les pare-feu ou les routeurs peuvent empêcher une connexion directe. Un mode « direct uniquement » devrait échouer clairement quand ce trajet n’est pas réalisable, plutôt que laisser croire qu’un relais est absent alors qu’il est utilisé.

Le protocole de contenu reste essentiel. Un trajet P2P n’authentifie pas automatiquement le correspondant et ne remplace ni les empreintes de clés ni le chiffrement applicatif choisi. Il ne promet pas non plus l’absence d’adresse IP ou de métadonnées visibles.

Mettre en relation sans confondre trajet et contenu.

La signalisation sert à négocier la connexion : elle peut transporter les descriptions de session et des informations permettant aux deux côtés d’essayer de se joindre. C’est un rôle distinct du transfert du contenu de la conversation. La documentation WebRTC décrit cette séparation et les échanges de candidats ICE. Référence : établissement d’une connexion WebRTC ↗

STUN aide à découvrir des informations utiles à la traversée des routeurs. ICE évalue les trajets possibles. Quand aucun trajet direct adapté n’aboutit, TURN peut fournir un relais si ce mode est configuré et autorisé.

Un produit peut donc viser des données qui circulent directement tout en utilisant des services pour la découverte, l’authentification ou la négociation. C’est pour cela que CryptoMail doit parler de « sans serveur de transit du contenu » dans le mode direct effectif, et non affirmer que toute son architecture fonctionne sans aucun serveur.

Un relais peut porter des données chiffrées.

Le relais intervient lorsqu’il faut transmettre les paquets entre deux appareils qui ne se joignent pas directement, ou lorsqu’une politique impose ce trajet. Dans les appels WebRTC de référence, TURN relaie des paquets protégés; il n’a pas, du seul fait de ce rôle, les clés permettant de lire le média.

Le relais observe néanmoins des informations nécessaires à son fonctionnement, notamment les adresses de connexion, les horaires et les volumes. Masquer l’adresse d’un participant à l’autre n’est donc pas synonyme de rendre toutes les métadonnées invisibles à tous les intermédiaires.

Le produit doit montrer la politique choisie et le trajet réel. Un mode automatique peut accepter un repli vers le relais; un mode strict doit respecter le choix explicite et signaler son indisponibilité. L’écran de contrôle ne doit pas afficher « P2P » seulement parce que cette préférence a été enregistrée.

Quand l’autre appareil n’est plus connecté.

Une connexion directe ne peut pas livrer immédiatement un message à un appareil éteint. Deux comportements sont prévus dans les politiques de référence : conserver le message localement jusqu’au retour du destinataire, ou déposer temporairement une enveloppe chiffrée sur un service pour une livraison différée.

Le mode local minimise le dépôt sur l’infrastructure, mais l’envoi dépend de la disponibilité ultérieure des appareils. La file chiffrée améliore la livraison asynchrone, avec des règles à définir sur la conservation, les accusés, l’expiration et les pièces jointes.

Une file recevant des enveloppes chiffrées reste un serveur dans le trajet de cette livraison. Le chiffrement de bout en bout vise à lui refuser le contenu lisible, pas à nier son existence. La connexion peut aussi révéler des métadonnées de service.

Tor et .onion : un mode à traiter séparément.

CryptoMail prévoit une option Tor et un service officiel .onion. Le but est de compléter la confidentialité du contenu par une protection du trajet. Les services Tor côté serveur ont été installés et testés. Le transport Tor dans l’application Android reste à développer et à valider : la bêta ne propose donc pas encore un mode Tor utilisable. Tor ne garantit pas un anonymat absolu. Référence : services onion du Tor Project ↗

Ce mode ne doit pas être présenté comme un direct P2P ordinaire caché par magie. Une connexion directe hors du circuit pourrait exposer une adresse IP et contredire l’intention de l’utilisateur. Le comportement des candidats réseau, du DNS, des notifications et des replis doit être évalué pour l’ensemble de l’application.

Un choix de routage strict doit avoir une réponse claire lorsqu’il est indisponible. Il ne doit pas basculer silencieusement vers une connexion directe et conserver une étiquette Tor à l’écran. Les protocoles de transport et les contraintes mobiles devront être testés avant cette intégration.

Tor ne peut pas annuler une identité révélée dans le contenu d’un message, sécuriser un appareil compromis ou garantir un anonymat absolu. Il traite une partie du modèle de confidentialité réseau; il complète les autres protections.

Le point précis sur la base de référence.

La documentation de référence décrit des appels audio et vidéo WebRTC individuels, une signalisation temporaire et les modes Direct, Auto et Relais privé. Elle prévoit aussi les politiques de livraison locale ou par file chiffrée pour les messages hors ligne.

La lecture du client de messagerie montre cependant que l’envoi des messages texte utilise encore l’API d’enveloppes chiffrées. Aucune intégration complète de canal de données P2P pour ces messages n’a été retrouvée dans le périmètre examiné. Les appels et le texte ne doivent donc pas être confondus.

Pour CryptoMail, le direct P2P est un objectif à intégrer, puis à tester entre de vrais comptes, sur différents réseaux et appareils. Il faut vérifier le trajet réel, les changements de réseau, les reprises, l’authentification et le traitement des échecs. Ce site explique ce fonctionnement visé; il ne prétend pas que le client mobile le propose déjà.