Silence est une application libre (GPL v3) pour Android de SMS et MMS, permettant de chiffrer les communications avec les autres utilisateurs de Silence. Silence vous permet donc d’envoyer du texte et des images en toute sécurité, mais le texte et les images passeront en clair par les réseaux vers les utilisateurs classiques. Cette application est disponible sous forme de code source sur GitHub et binaire sur F-Droid et le Play Store de Google.
Silence est le nouveau nom de SMSSecure, divergence (fork) de Signal (anciennement TextSecure) d’Open Whisper Systems. On avait déjà parlé de l’abandon du chiffrement des SMS et MMS de Signal, à cause des limites des API d’iOS, d’une expérience utilisateur compliquée en ce qui concerne l’échange de clefs et aussi des méta‐données des SMS et MMS qui transitent forcément en clair. Silence/SMSSecure était né de ce constat, ainsi que de la volonté de se débarrasser des dépendances aux services de Google.
Un transport XMPP est actuellement en cours d’ajout dans Silence.
Chiffrement des SMS et MMS et des méta‐données
Le rôle premier de Silence est de chiffrer les SMS et MMS entre deux utilisateurs de l’application. C’est une des raisons historiques du fork de l’application, quand TextSecure a abandonné cette fonctionnalité.
Après un échange de clefs, l’utilisateur pourra, de manière simple et transparente, chiffrer ses communications par SMS avec les autres utilisateurs de Silence. Et pour les autres contacts qui n’utilisent pas l’application, Silence se comportera comme n’importe quelle application de SMS, c’est‐à‐dire que les messages ne seront pas chiffrés.
Le gros problème des SMS est qu’ils laissent beaucoup de méta‐données. Les méta‐données, globalement, qui parle à qui, quand et à quelle fréquence, permettent de calculer des graphes sociaux et sont massivement utilisées par les agences de renseignement. Silence ne peut pas masquer les méta‐données, puisque celles‐ci sont intrinsèquement nécessaires pour que le SMS soit correctement envoyé. Les opérateurs téléphoniques (ainsi que les agences ayant accès aux bases de données des opérateurs) peuvent donc savoir vers quels numéros un utilisateur discute, même si le contenu des messages reste inaccessible grâce au chiffrement de bout en bout du message par Silence.
Le projet parent de Silence, TextSecure (aujourd’hui Signal), a choisi de se concentrer sur les messages qui passent par Internet. Les opérateurs téléphoniques n’ont alors pas accès aux méta‐données. En revanche, TextSecure/Signal utilise les services de Google. Même si un effort est fait pour réduire les informations exploitables par la firme, des méta‐données restent accessibles à Google. En outre, TextSecure/Signal n’a pas de système fédéré de serveurs et l’intégralité des contacts des utilisateurs est sauvegardée en ligne.
Les méta‐données des SMS sont un vrai problème et il est nécessaire de proposer une solution. Cependant, il ne s’agit pas de supprimer la prise en charge des SMS et MMS, mais seulement de proposer une meilleure solution. XMPP étant décentralisé et ouvert, Silence se dirige vers ce choix et va bientôt permettre de transmettre les messages via XMPP.
XMPP
XMPP est décentralisé. Mais il faut quand même un certain nombre de paramétrages côté serveur, tant en termes de sécurité que de fonctionnalités (notamment la XEP-0198 : Stream Management pour ne pas perdre de messages quand la connectivité est mauvaise).
Pour acheminer les messages XMPP, il vaut mieux se reposer sur des serveurs gérés par des organisations en qui on peut avoir relativement confiance. Certes, les messages continueront d’être chiffrés de bout en bout et ne pas avoir confiance en son serveur XMPP n’est pas rédhibitoire. Pour autant, c’est un plus appréciable.
Ainsi, Silence va intégrer une liste de serveurs XMPP « de confiance », c’est‐à‐dire répondant aux critères de sécurité, de configuration et opérés par des organisations à but non lucratif. Bien entendu, il vaut mieux un grand nombre de serveurs afin de réduire l’intérêt et les dégâts potentiels d’une attaque.
Prenons Bob qui envoie un message à Alice. Bob est connecté à son serveur XMPP : le serveur de Bob voit un message en provenance d’une adresse XMPP inconnue (il n’y a pas de lien entre l’adresse XMPP de Bob et le numéro de téléphone de Bob ; le serveur ne connaît même pas l’identité réelle de Bob) à destination d’une autre adresse XMPP inconnue. Le serveur de Bob connaît l’adressee IP qui s’est connectée, mais il ne peut pas l’associer à une personne (encore moins si Bob passe par Tor). Il ne connaît pas non plus l’adresse IP d’Alice. Le serveur XMPP d’Alice voit arriver un message XMPP, mais il ne connaît pas l’adresse IP de Bob. En outre, les FAI de Bob et Alice ne connaissent pas les adresses XMPP, puisque les connexions sont encapsulées dans TLS. Et aucun contact n’est envoyé en ligne, tout reposant sur le carnet d’adresses local de chaque utilisateur.
Appel aux hébergeurs
Silence doit donc reposer sur un « réseau » composé d’opérateurs de serveurs XMPP. De tels opérateurs peuvent être des associations, des fédérations d’hébergeurs (au hasard, des membres du collectif Chatons), des hébergeurs indépendants, etc. Ce « réseau » doit être mis en place avant la publication de la première version de Silence, ajoutant le transport XMPP, puisque l’utilisateur va créer un compte sur un de ces serveurs en fonction de la liste incluse dans l’application. Il sera bien sûr également possible pour l’utilisateur de paramétrer un autre serveur s’il le souhaite.
Si vous êtes intéressés par le projet, envoyez un courrier électronique à « support chez silence point im » ! ;)
Aller plus loin
- Site du projet (437 clics)
- Code source de Silence (129 clics)
- Silence sur F-Droid (147 clics)
# Fédération ?
Posté par Gastlag . Évalué à 10.
Est-ce que Silence, en particulier sa fonctionnalité de chiffrement, est compatible avec le client Conversations ou tout autre client XMPP utilisant le protocole de chiffrement OMEMO ?
[^] # Re: Fédération ?
Posté par BastienLQ . Évalué à 4.
Il ne s'agit pas d'OMEMO, lequel repose sur PEP. L'implémentation dans Silence est vraiment très légère : le contenu chiffré est envoyé via XMPP au lieu d'être envoyé via SMS. Il n'y a pas non plus de reconnaissance via XMPP des contacts qui utilisent Silence : pour l'instant, la communication chiffrée via XMPP repose sur l'établissement préalable d'une session chiffrée via SMS (l'adresse XMPP est échangée au moment de l'échange des clés publiques).
À terme, l'idée est de pouvoir établir une session chiffrée via XMPP et de s'envoyer son numéro de téléphone en même temps que les clés. Mais ça, je m'en occuperai après. Le gros avantage est que cela permettra de développer un client iOS de Silence (sans chiffrement des SMS, certes), chose impossible avec uniquement du chiffrement de SMS puisqu'iOS interdit à une application tierce de gérer les SMS du téléphone.
# cli
Posté par Anonyme . Évalué à 4.
Je profite de ce journal pour soulever un problème pratique: je n'ai pas trouvé de client en ligne de commande pour le protocole utiliser par Silence.
J'utilise une passerelle web pour envoyer certains sms, et j'aimerais bien pouvoir les chiffrer avant de les envoyer.
Connaîtriez vous un outil de ce type ?
Pour ce qui concerne le journal en lui même, j'ai du mal à comprendre l'intérêt de faire de Silence un client XMPP.
Ce logiciel répond à une problématique précise: besoin de confidentialité des échanges dans le cas d'une impossibilité de communiquer via un accès à internet.
Ce n'est pas parfait et je lui préfère naturellement XMPP via Conversation quand j'ai accès à une connexion internet.
Ce sont pour moi deux cas d'usage différents dans leur niveau de mise en place d'une confidentialité des échanges.
La séparation des deux logiciels me permet de bien garder à l'esprit qu'ils ne sont pas équivalents de ce point de vue.
Mélanger les deux dans un seul logiciel comme Silence semble vouloir le faire, ne me parait pas être une bonne idée, sauf à prioriser XMPP par rapport au SMS et à mettre en place une signalétique qui rappelle clairement à l'utilisateur avec quel niveau de confidentialité il est en train de communiquer.
[^] # Re: cli
Posté par Anonyme . Évalué à 2.
s/journal/dépêche/g
[^] # Re: cli
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
Tu profites de ce dépêche, donc ? :)
[^] # Re: cli
Posté par Anonyme . Évalué à 4.
Et forcément en allant voir la PR après avoir écrit mon message je m'aperçois que tout ce dont je parle ci-dessus est implémenté.
Donc je sors en attendant de tester cette nouvelle mouture.
[^] # Re: cli
Posté par BastienLQ . Évalué à 6.
L'intérêt des messages XMPP dans Silence est de proposer une solution de communication chiffrée sans laisser trop de traces en terme de méta-données. Silence est conçu pour remplacer l'application de SMS du téléphone : c'est pour cela que les SMS chiffrés ne seront jamais supprimés. Sauf qu'en proposant les messages XMPP en plus des SMS, cela permet aux utilisateurs d'avoir une interface unique pour communiquer de manière sécurisée. C'est beaucoup plus facile que d'avoir deux applications : il n'y a pas deux applications à paramétrer, pas besoin de s'occuper de l'adresse XMPP de son correspondant, etc. Dans Silence, lorsque 2 contacts s'échangent leurs clés publiques, les adresses XMPP sont également partagées et la bascule sur des messages XMPP se fera automatiquement lorsqu'il y aura un accès Internet. Et lorsqu'il n'y a pas d'accès Internet pour l'une des deux parties, Silence continuera d'utiliser les SMS (sauf demande explicite de l'utilisateur).
# Faut bien encourager :)
Posté par Noobinux . Évalué à 7.
Bonjour,
Tout d’abord bravo pour votre superbe travail, j’utilise SMSSecure/Silence depuis le tout début et j’en suis pleinement satisfait, votre travail est exemplaire ! :)
Ensuite, je fais partie d’associations membres du collectif CHATONS, je m’empresse de faire passer le mot, je le repasserais lors d’AG ou CT sans aucun soucis, d’autant que (presque) tous les membres des CT que je connais utilise SMSSecure/Silence depuis le début de votre fork.
Encore bravo, et à bientôt !
[^] # Re: Faut bien encourager :)
Posté par Maclag . Évalué à 8.
Et puis pour dire que les journaux et dépêches, ça sert: je viens personnellement de l'installer, et je regrette d'avoir manqué l'occasion la dernière fois. Et un autre argument pour mettre la famille au serveur XMPP familial.
# Petite précision
Posté par rakoo (site web personnel) . Évalué à 7.
XMPP fait tout pour ne pas perdre les messages, de base. Soit la connexion de bout en bout est vivante et le message est transmis, soit il y a un problème sur la ligne et les serveurs vont faire ce qu'ils peuvent pour retransmettre le message quand l'autre coté se réveille. Ce que fait la XEP-198, c'est faire en sorte que l'utilisateur ne voit pas d'interruption quand la connexion est coupée temporairement, et que son smartphone ne refasse pas toute la danse nécessaire a chaque reconnexion. En ce qui concerne les messages eux-mêmes, pour s'assurer a 100% qu'ils ne soient pas perdus c'est la XEP-0184 qu'il faut utiliser.
# Confiance dans le serveur XMPP
Posté par Maclag . Évalué à 7.
Je pense que c'est important. L'avantage d'XMPP ici c'est que l'opérateur ne sait plus non plus à qui tu parles. Si le serveur XMPP fournit l'info, il suffit d'associer le contact au numéro de tél, et paf: l'opérateur sait à qui tu parles, à quelle fréquence, avec quel volume d'échange.
# My 2 cents
Posté par tuxicoman (site web personnel) . Évalué à 4.
Voici mes commentaires sur ton idée :
Sur XMPP, la liste de contacts est stockée sur le serveur en clair (dans la BDD)
Donc l'admin a connaissance de ton carnet d'adresse. Sur Silence, ce carnet d'adresse reste sur ton appareil.
Le serveur XMPP note qui se connecte, quand, de quelle IP et qui communique avec qui.
La connexion Serveur/Client est permanent. Donc le serveur sait quand je change de réseau wifi à 3G, à quelle heure je rentre chez moi si j'ai la même IP tous les soirs, etc…
Le FAI peut savoir qui est derrière une IP. Je suppose qu'une attaque par timing suffirait pour savoir qui converse avec qui en étudiant les communications d'un petit serveur XMPP.
Il existe Conversations sur Android https://conversations.im/ qui est un bon client XMPP (envoi de messages, photos et fichiers chiffrés de bout en bout si on le souhaite, sinon au moins jusqu'au serveur). XMPP est découpé en XEP et il faut supporter vraiment beaucoup de XEP pour que le client ressemble à quelque chose d'utilisable sans trop de complication (genre envoi d'image/fichier derrière un NAT, détection si le message est arrivé à destination, message hors ligne, gestion de connexion instable (perte/reconnexion de 3G/wifi) etc…)
Le point fort de l'identification par le numéro de telephone, c'est qu'on a pas besoin d'un échange par un canal tiers préalable pour commencer à converser ou remplir sa liste de contacts. Ca facilite grandement la pénétration (cf whatsapp et signal)
Est ce que Silence se baserait toujours sur le numéro de tel comme identifiant? Sinon, quelle différence face à Conversations?
Sinon, un des problèmes du chiffrement de bout en bout est qu'on ne peut passer d'un appareil à l'autre. Par exemple, j'aime bien commencer une conversation sur smartphone et la terminer sur PC (par exemple pour taper plus confortablement ou ouvrir des liens) Dans ce cas, c'est pratique si quand on ouvre le client XMPP sur le PC, il peut récupérer l'historique des derniers messages recus sur le smartphone. (le message qui contenait le lien HTML super long par exemple :)
Actuellement, la configuration pratique que j'ai trouvée https://tuxicoman.jesuislibre.net/2016/09/modules-pratiques-pour-serveur-prosodyxmpp.html est de laisser le serveur garder un historique des dernier messages recus et de broadcaster les messages recus sur tous les appareils clients. Mais ca va à l'encontre du chiffrement de bout en bout. On devrait pouvoir trouver une solution où nos clients personnels s'échangent entre eux les derniers messages par exemple.
[^] # Re: My 2 cents
Posté par Maclag . Évalué à 6.
D'où le besoin de faire confiance au serveur!
Sinon pourquoi pas proposer une modif du protocole pour chiffrer les infos des contacts?
Est-ce que t'as besoin de tant que ça pour remplacer des MMS?Est ce que Silence se baserait toujours sur le numéro de tel comme identifiant?
Avoir un seul outil pour les messages PAS instantanés, en laissant à Conversation l'instantané.
Encore une fois, on ne parle pas de la même chose: discussions instantanées contre pas instantanées
Ou qu'on puisse utiliser une seule clé privée sur tous les appareils? (Ça marcherait?)
[^] # Re: My 2 cents
Posté par J'informatique (site web personnel) . Évalué à 0.
Il existe déjà une solution, regarde par exemple l'application Wire.
https://www.wire.com
[^] # Re: My 2 cents
Posté par BastienLQ . Évalué à 2.
Les deux serveurs XMPP (celui d'Alice et celui de Bob) savent qu'elles adresses XMPP parlent avec qui. Ça, c'est certain.
Cependant, les adresses XMPP dans Silence ne sont pas conçues pour être utilisées dans un autre contexte que dans Silence. Les adresses utilisées sont des UUID : pas de nom.prenom@, pas de 0612345678@. Utiliser un UUID (en fait, utiliser n'importe quoi de généré aléatoirement) permet d'éviter les risques de collision. En effet, si j'utilise la même adresse XMPP dans Silence qu'ailleurs, les risques de collisions sont grands et les attaques rendues moins difficiles.
En outre, aucune info de contacts n'est envoyée via XMPP : la découverte des utilisateurs utilisant Silence se base sur le carnet d'adresses local du téléphone et l'échange de l'adresse XMPP au moment de l'initialisation des sessions chiffrées.
Pour les MMS, c'est également possible en théorie dans Silence. Je suis néanmoins confronté à un problème technique. Historiquement, un message multimédia était échangé en initialisant une connexion directement de l'expéditeur vers le destinataire. Ensuite, le développeur de Conversations a travaillé sur un mécanisme similaire aux MMS, c'est-à-dire l'envoi du fichier multimédia sur un serveur distant, qui sera ensuite récupéré par le destinataire avec les jetons d'authentification transmis par l'expéditeur. Le gros avantage est que cela ne nécessite pas que les deux contacts soient connectés au moment de l'envoi du fichier. Ça, c'est la XEP-0363: HTTP File Upload. Prosody supporte cette XEP (je n'ai pas regardé les autres serveurs). Le problème, c'est que Smack, la bibliothèque utilisée dans Silence pour XMPP, ne supporte pas cette extension.
Pour ce qui est du support multi-appareils, il y a un blocage lié au fait que le numéro de téléphone reste le moyen d'identifier un contact et que l'envoi de SMS ne se fait que vers un seul appareil (Silence reste une application de SMS). C'est mille fois plus facile de ne transmettre qu'un numéro de téléphone plutôt qu'une adresse XMPP (qui plus est, générée aléatoirement). J'avais il y a quelques temps commencé à travailler sur une API REST pour gérer à distance les SMS/MMS du téléphone : un client quelconque peut ensuite se connecter au téléphone pour gérer les SMS/MMS à distance. Je n'ai jamais terminé cette fonctionnalité, et comme ce n'est pas une fonctionnalité si demandée que ça, je me suis concentré sur d'autres choses. L'idée de Silence est vraiment d'être un moyen de communication d'un téléphone vers un autre téléphone. Certes, c'est plus simple d'écrire un long SMS depuis son ordinateur, d'où l'idée de l'API REST.
# iOS
Posté par claudex . Évalué à 4.
Est-ce que ce serait possible techniquement de porter l'application sur iOS? Parce que n'avoir que des contacts sur Android ça limite la quantité de messages chiffrés.
Bon, je dis ça mais je ne l'utilise pas, je préfère envoyer des mails depuis mon smartphone. Ce n'est pas autant chiffré mais au moins, c'est du TLS de bout en bout (vu que mon serveur chiffre et que mes contacts sont sur Gmail). Et je peux les retrouver sur mon PC.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: iOS
Posté par BastienLQ . Évalué à 3.
iOS n'autorise pas une application tierce à gérer les SMS/MMS. Porter Silence actuellement est donc impossible. En revanche, avec XMPP, il sera possible à terme de porter une version sans le chiffrement des SMS sur iOS : https://linuxfr.org/news/silence-xmpp-chiffrement-et-meta-donnees#comment-1685277
[^] # Re: iOS
Posté par claudex . Évalué à 4.
C'est bien ce qu'il me semblait, c'est dommage.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: iOS
Posté par groumly . Évalué à 3.
Pourquoi se limiter au SMS?
Surtout si les opérateurs ont accès aux métadonnées?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Méta-données
Posté par Eiffel . Évalué à 4.
À un moment j'avais entendu parler du logiciel Ricochet qui permet de communiquer sans méta-données.
Quelqu'un connaît et l'a testé ?
Après il n'y a pas d'application pour smartphone du coup je squatte un peu la news…
[^] # Re: Méta-données
Posté par taziden (site web personnel) . Évalué à 1.
Ricochet fonctionne très bien ;) Je l'utilise avec quelques contacts pour les conversations nécessitant le plus de discrétion.
# Divergence ?
Posté par Papey . Évalué à 2.
Bifurcation ne serait pas plus adapté comme traduction de fork ? Divergence ça fait un peu pathologique.
[^] # Re: Divergence ?
Posté par ariasuni . Évalué à 2.
Pathologique? Divergence n’est pas le nom d’une maladie. Après je me dis que le terme est pratique vu qu’il existe convergence quand deux projets se réunissent (mais bifurcation a le mérite d’être moins ambigu).
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Divergence ?
Posté par Papey . Évalué à 2.
Fusion paraît mieux adapté que "convergence" ? La convergence implique un horizon temporel étendu, une feuille de route. La fusion quant à elle peut se faire sur un temps court.
# Wire
Posté par J'informatique (site web personnel) . Évalué à -2.
Plutôt que de réinventer la roue, ou faire quelque chose de similaire à ce qui existe déjà, pourriez-vous tester Wire ?
C'est une messagerie équivalente à Skype en terme de fonctionnalités mais dont les clients sont open source et la partie serveur sera complètement open source en mars 2017.
Wire utilise le chiffrement de bout en bout par défaut pour tous les types d'échange : messages textes, appel audio et vidéo, transfert de fichiers. Qualité audio avec le codec opus en 48 kHz.
Synchronisation des messages avec vos multiples appareils pour le même compte.
https://www.wire.com
[^] # Re: Wire
Posté par ariasuni . Évalué à 4.
L’inconvénient majeur de Wire par rapport aux SMS, au courriel ou à Jabber c’est que c’est centralisé. On va pas pousser des gens à migrer d’un truc centralisé vers un autre truc centralisé…
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Wire
Posté par J'informatique (site web personnel) . Évalué à 1.
Effectivement c'est un inconvénient majeur dont je suis conscient. Le jour ou un équivalent à Wire basée sur XMPP en logiciel libre client et serveur existera, intégrant le chiffrement de bout en bout PAR DÉFAUT, c'est à dire où l'on ne doit pas expliquer à l'autre qu'il doit cliquer sur le cadenas pour chiffrer sa communication, là, à ce moment là on pourra en parler et j'adopterais cet outil tout de suite.
En attendant, on y est pas et la seule alternative complète utilisant du chiffrement bout en bout, pour les messages et les appels, à 2 ou plusieurs, c'est Wire. Donc en attendant je recommande cela. Sauf s'il existe mieux dont je ne suis pas au courant et qui est facile d'accès à un non-informaticien, faites le moi savoir.
[^] # Re: Wire
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 2.
Justement, Conversation (un client XMPP pour Android) supporte OMEMO pour le chiffrement de bout en bout depuis quelques versions, mais il fallait l'activer manuellement, puis autoriser les signatures des périphériques un à un.
Comme cette démarche est difficile en pratique, et ils viennent de sortir une version (1.15) qui apporte une amélioration intéressante dans ce sens: ils proposent d'activer un chiffrement par défaut pour tous les périphériques tant qu'aucune authentification n'a été réalisée.
Quand le processus d'authentification est réalisé (par le scan d'un QR Code [obtenu par un autre canal sécurisé] au lieu du contrôle manuel et fastidieux des signatures [obtenu par le même canal XMPP]), ils considèrent que l'utilisateur est capable d'authentifier les périphériques des contacts authentifiés et ne chiffrent plus que pour ces périphériques.
Je trouve la démarche intéressante, car il permet de ne pas tomber dans un modèle où tout est chiffré sans authentification réelle des utilisateurs, mais il permet quand même aux utilisateurs sans capacités à réalisé l'authentificaiton (soit de sa part, soit de la part du contact) d'avoir le minimum du chiffrement.
Désolé si ce n'est pas très claire, j'ai lu leur explication du principe ce matin plus ou moins en vitesse et je ne suis pas sûr d'avoir tout compris. Je vous conseille donc de lire leur post original qui détaille plus la situation actuelle et la solution intermédiaire qu'ils ont mis en place.
[^] # Re: Wire
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
ce n'est pas forcément simple ou désirable.
À l'heure actuelle il y a 3 méthodes de chiffrement de bout en bout:
1) OTR, qui ne gère pas les appareils multiples, ne permet pas l'historique sur le serveur, et ne chiffre pas toute la stanza (seulement le corps)
2) OX (OpenPGP moderne) qui gère chiffrement de toute la stanza, appareils multiples, et archives serveurs, mais qui ne gère pas la confidentialité persistante et qui fait augmenter considérablement la taille des données
3) OMEMO qui ne gère pas le chiffrement de toute la stanza (il le fera peut-être dans le futur), qui gére les appareils multiples et la confidentialité persistante, mais qui ne permet pas les archives serveur.
Le chiffrement de la stanza complète bloque certaines fonctionnalités (le serveur a parfois besoin de savoir ce qui passe), de même que l'impossibilité d'avoir les archives sur le serveur.
D'autre part si tu as confiance en ton serveur et en celui de ton correspondant, le chiffrement de bout en bout n'est pas forcément nécessaire.
Bref, le problème n'est pas si simple qu'il parait, et le chiffrement de bout en bout par défaut n'est pas forcément souhaitable (à l'heure actuelle).
Et je passe sur le fait que les XEPs ne sont qu'expérimentales (OMEMO n'est une XEP officielle que depuis quelques jours d'ailleurs).
# I love signal
Posté par Régis . Évalué à 1. Dernière modification le 13 décembre 2016 à 20:45.
Hello,
J'utilise signal tous les jours avec de nombreux contact.
Le coté centralisé me gène mais ta solution propose d'éparpiller les meta informations entre plusieurs acteurs.
Effectivement c'est un plus.
Mais quid de la voip avec Zrtp dans ton projet ?
Quid du link avec le browser (Chrome / Chromium) ?
Franchement je ne bougerais vers un fork de signal que si j'ai une garentit cryptographique (un peu comme avec le réseau onion de tor) que les metas informations ne peuvent pas fuiter.
Avec ton projet je vois ce que je perd (VoIP / Association avec mon brouteur afin que j'ai toujours mes messages partout) mais ce que je gagne c'est de déporter ma confiance pour mes metas informations envers des tiers inconnus.
Et franchement le support du SMS à part en afrique ou tu est complètement déconnecté je m'en tamponne :)
Le truc qui me casse le plus les "couilles" dans signal c'est l'authentification par SMS qui est pourrav à la premièrre utilisation mais bon c'est vrais que cela simplifie la vie des utilisateurs lambda.
Mais c'est sympa de voir des gens faire des efforts, c'est cool et je te souhaite une bonne réussite.
PS : Réfléchie à une solution mathématique pour préserver les meta information. Rapproche toi du mec qui fait crypto cat, il travaille sur la question. La prochaine bataille ce joue à ce niveau.
Regarde aussi le protocole Z Cash pour remplacer le bitcoin traçable.
Librement et vive les forks ;))
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.