- This topic is empty.
- Articles
Discrétion vs sécurité
Une réalité est souvent ignorée: la robustesse cryptographique d’un algorithme ne protège pas grand monde si l’architecture globale fuit des métadonnées ou dépend d’acteurs soumis à des lois extraterritoriales.
Il faut donc séparer deux notions:
- La discrétion structurelle: qui parle à qui, quand, à quelle fréquence, depuis quelle adresse IP, avec quel appareil.
- La sécurité du contenu: le chiffrement des messages proprement dit.
Ces deux dimensions sont liées, mais elles ne se confondent pas. Une application peut très bien protéger le contenu des messages tout en exposant une grande partie du graphe social ou des habitudes de communication.
WhatsApp, Telegram, Olvid, SimpleX, Session et Element: quelle hiérarchie?
WhatsApp contre Telegram: contenu chiffré, mais mauvaise discrétion
WhatsApp est plus sûr que Telegram pour le contenu en usage standard, parce que WhatsApp chiffre les messages personnels de bout en bout par défaut, alors que Telegram ne le fait que dans les “Secret Chats”.
Les conversations Telegram ordinaires sont des “Cloud Chats”: elles sont stockées côté Telegram, avec un chiffrement client-serveur, mais sans chiffrement de bout en bout. Telegram peut donc être pratique, rapide et riche fonctionnellement, mais il ne doit pas être confondu avec une messagerie confidentielle par défaut.
En revanche, WhatsApp reste faible en confidentialité et en souveraineté: numéro de téléphone obligatoire, dépendance à Meta, collecte d’informations d’usage, métadonnées, appareils, interactions, horaires, fréquence d’utilisation, carnet social et transferts internationaux. Le contenu peut être bien protégé, mais la discrétion structurelle reste mauvaise.
Conclusion: WhatsApp protège mieux le contenu que Telegram normal, mais n’est pas une bonne solution de confidentialité souveraine.
Confidentialité / souveraineté
1. SimpleX
SimpleX est le plus cohérent avec un principe de confidentialité stricte: pas d’identifiant utilisateur global, pas même aléatoire, pas de numéro de téléphone, pas d’e-mail, contacts et groupes locaux, relais remplaçables ou auto-hébergeables.
L’objectif est clair: empêcher qu’un opérateur unique puisse reconstituer le graphe social. Dans une logique de discrétion structurelle, SimpleX est probablement le meilleur choix.
2. Session
Session est également très bon pour la discrétion: pas de numéro, pas d’e-mail, routage en oignon et réseau de nœuds. Il limite fortement l’exploitation des métadonnées par un opérateur central.
La première version du protocole avait toutefois une faiblesse notable: l’absence de Perfect Forward Secrecy complète. Le protocole Session V2 vise à corriger cette faiblesse en réintroduisant la PFS et en ajoutant des briques post-quantiques.
3. Element / Matrix auto-hébergé et fermé
Element peut être très intéressant si l’infrastructure est réellement contrôlée: serveur auto-hébergé, fédération fermée, sauvegardes maîtrisées, politique d’inscription stricte et chiffrement correctement configuré.
Mais Matrix devient beaucoup moins discret si l’on utilise un gros homeserver public ou une fédération ouverte. Même avec chiffrement de bout en bout, certaines métadonnées de salons restent visibles côté serveur: appartenance aux salons, états, noms, sujets, volumes et temporalités.
Element est donc excellent dans un cadre maîtrisé, mais plus complexe à sécuriser correctement.
4. Olvid
Olvid est un très bon concept cryptographique: pas besoin de numéro, authentification forte des contacts, chiffrement de bout en bout et modèle prétendant réduire la confiance dans le serveur.
Mais Olvid n’est pas le meilleur choix dans une grille de lecture de souveraineté stricte. Dès lors que l’infrastructure dépend d’AWS, l’argument “sans tiers de confiance” doit être compris au niveau du protocole, pas au niveau de la souveraineté opérationnelle.
AWS est une société américaine, soumise au droit américain. Même si AWS ne peut pas lire directement le contenu des messages chiffrés, l’infrastructure peut rester exploitable sur d’autres plans: adresses IP, volumes, horaires, ciphertexts, journaux techniques, contraintes légales, attaques futures ou compromission d’un composant périphérique.
Olvid peut donc être fort cryptographiquement, mais faible en souveraineté.
5. Telegram Secret Chats
Les Secret Chats de Telegram sont acceptables pour des échanges ponctuels en 1:1, avec vérification des clés.
Mais ce n’est pas le mode normal de Telegram. Ils ne sont pas adaptés à l’usage principal de l’application, ne couvrent pas les groupes de manière équivalente et restent marginaux dans l’expérience utilisateur.
6. WhatsApp
WhatsApp offre un très bon chiffrement du contenu, mais reste incompatible avec une confidentialité forte: numéro obligatoire, dépendance à Meta, application fermée, collecte de métadonnées, sauvegardes cloud possibles et infrastructure centralisée.
C’est une bonne messagerie de masse pour protéger le contenu contre des tiers ordinaires. Ce n’est pas une messagerie de souveraineté.
7. Telegram Cloud Chats
Telegram normal est le plus faible pour la confidentialité réelle. Les Cloud Chats ne sont pas chiffrés de bout en bout et reposent sur une infrastructure propriétaire opaque.
Telegram peut être utile pour la diffusion, les canaux publics, les communautés ou l’usage social. Mais il ne doit pas être présenté comme une solution de confidentialité sérieuse en usage standard.
Points clefs
1. Le paradoxe Olvid et la dépendance à AWS
La critique concernant Olvid touche le cœur du problème de la souveraineté numérique.
L’illusion du zéro-confiance au niveau protocolaire
Le protocole cryptographique d’Olvid peut éliminer le besoin d’un annuaire centralisé et d’un tiers de confiance pour valider les clés. Mais l’infrastructure physique reste centralisée chez Amazon Web Services, c’est-à-dire AWS.
Cette distinction est essentielle: un protocole peut réduire la confiance dans le serveur sans supprimer la dépendance à un opérateur, à un hébergeur et à un droit applicable.
Risque juridique et technique
AWS est une entreprise américaine, soumise au Cloud Act et à la section 702 de la FISA. Même si AWS ne peut pas lire directement le contenu des messages chiffrés, la centralisation des flux peut permettre la collecte d’adresses IP, l’analyse des volumes de trafic, la corrélation des horaires et le stockage massif de ciphertexts.
Le stockage de données chiffrées sur des serveurs tiers expose aussi au risque du “Store Now, Decrypt Later”: intercepter et stocker aujourd’hui pour tenter de déchiffrer demain, notamment avec l’avènement de l’informatique quantique.
Le vrai risque n’est donc pas seulement le cassage mathématique du chiffrement. Il est aussi dans l’exploitation des métadonnées, des journaux, des contraintes légales, des failles client, des mises à jour forcées et des compromissions périphériques.
2. L’évolution du protocole Session
La remarque sur l’absence de Perfect Forward Secrecy, ou PFS, dans la première version de Session est exacte.
L’abandon initial du protocole Signal par Session visait à stabiliser l’application sur un réseau décentralisé à nœuds, l’Oxen Service Node Network, mais au détriment de la PFS.
Mise à jour du protocole
Le protocole Session V2 vise à corriger cette faiblesse. Cette mise à jour réintroduit la PFS via un système de paires de clés rotatives par appareil et par compte, tout en intégrant des algorithmes de cryptographie post-quantique comme ML-KEM.
Cela comble la vulnérabilité historique de Session sur ce point, tout en conservant l’objectif principal: minimiser les métadonnées et éviter la dépendance à un opérateur central.
3. La relativité des certifications ANSSI
L’analyse de la Certification de Sécurité de Premier Niveau, ou CSPN, doit rester lucide.
Limitation de la CSPN
Une CSPN évalue un produit à un instant donné, selon un périmètre restreint et face à un attaquant de niveau modéré. Elle ne garantit ni l’invulnérabilité à long terme, ni la résistance face à des agences de renseignement étatiques.
Obsolescence des versions
Le fait que les versions certifiées d’Olvid soient marquées comme “Non maintenues” dans le catalogue de l’ANSSI confirme que la sécurité opérationnelle exige une maintenance continue.
Une certification peut avoir une valeur ponctuelle. Elle ne remplace pas les audits récurrents, la transparence du code, la vérifiabilité des builds, la revue publique du protocole et la résilience opérationnelle.
Synthèse
Application Chiffrement de contenu Protection des métadonnées Souveraineté de l’infrastructure Anonymat à l’inscription SimpleX Excellent, avec Double Ratchet et post-quantique Excellente: aucun identifiant global, routage par files Modulaire: relais modifiables ou auto-hébergeables Total: aucun numéro ni e-mail Session V2 Bon: PFS réintroduite et post-quantique Excellente: routage en oignon par nœuds Décentralisée: réseau de nœuds Oxen Total: aucune donnée personnelle requise Element fermé Très bon: protocole Matrix Moyenne: métadonnées de salons visibles par le serveur Totale si l’infrastructure est auto-hébergée Optionnel selon la configuration du serveur Olvid Excellent: chiffrement de bout en bout complet Bonne: pas d’annuaire centralisé Faible: dépendance stricte à AWS Total: aucun identifiant requis WhatsApp Excellent: protocole Signal Mauvaise: collecte Meta, IP, graphe social, usages Nulle: infrastructure centralisée de Meta Nul: numéro de téléphone obligatoire Telegram normal Faible: chiffrement client-serveur par défaut Mauvaise: contenu et métadonnées stockés dans le cloud Centralisée: infrastructure propriétaire opaque Nul: numéro de téléphone obligatoire Classement
Confidentialité / souveraineté stricte
SimpleX > Session > Element auto-hébergé fermé > Olvid > Telegram Secret Chat > WhatsApp > Telegram Cloud
Ce classement privilégie la minimisation des métadonnées, l’absence d’identifiant stable, l’absence de numéro de téléphone, la réduction de l’opérateur central et la capacité à contrôler ou remplacer les relais.
Sécurité cryptographique du contenu
SimpleX / Olvid > WhatsApp > Element bien configuré > Session > Telegram Secret Chat > Telegram Cloud
Ce classement privilégie le chiffrement du contenu, l’authentification, la résistance à l’interception directe et la maturité cryptographique.
Conclusion
Le maillon faible d’une communication sécurisée réside rarement dans le cassage direct d’AES ou du Double Ratchet. Il se trouve plutôt dans les failles périphériques: compromission des terminaux, analyse des métadonnées de transport, contraintes légales sur les hébergeurs centralisés, substitution de clés, mises à jour piégées ou conservation de ciphertexts pour une exploitation future.
La confidentialité ne se réduit donc pas au chiffrement. Une application peut chiffrer correctement les messages tout en restant fragile sur le plan de la souveraineté, si elle dépend d’une infrastructure centralisée, d’un acteur étranger ou d’un hébergeur soumis à des lois extraterritoriales.
WhatsApp est plus sûr que Telegram normal pour le contenu, mais pas plus confidentiel au sens fort. Olvid est solide cryptographiquement, mais beaucoup moins convaincant dès que le critère principal devient la souveraineté et la défiance envers l’opérateur.
Dans cette grille de lecture, SimpleX, Session et un Element réellement auto-hébergé et fermé sont plus cohérents qu’Olvid pour la confidentialité et la souveraineté, même si Olvid peut rester théoriquement solide sur le plan cryptographique.
- SimpleX Chat : Dépôt GitHub officiel de SimpleX
- Session : Dépôt GitHub officiel de Session Desktop
- Element (Matrix) : Dépôt GitHub officiel d’Element Web
- Olvid : Site officiel d’Olvid
- WhatsApp : Site officiel de WhatsApp
- Telegram : Site officiel de Telegram
Un jeune site que j'aime bien, la ferrari du T-shirt ...bio en plus : GoudronBlanc
- Vous devez être connecté pour répondre à ce sujet.