TextSecure n'a jamais vendu une quelconque confidentialité des méta-données.
Personne ne pourra jamais confirmer cela. Si le serveur de textsecure y était contraint, le pourrait-il? On retombe sur le schema de Lavabit.
Comme dit plus haut, le hash du tel, même salé, c'est faible pour masquer l'identité des communiquants. Mais chacun sa notion de "secure".
Pour revenir au sujet. Je suis d'accord avec toi, le spam est le problème de ma solution.
Pour contrecarrer cela, je pensais :
1. Donner un token aux contacts dont j'accepte les messages. Ce token, envoyé avec les messages à ma destination permettrait au messages d'etre traités prioritairement par rapport aux autres messages reçus.
Les messages d'inconnus (sans token) doivent avoir une preuve de travail, ce qui limite un peu le spam.
2. Recevoir les messages par l'intermédiaire d'un serveur (comme un serveur de mail). Ce serveur pourrait filtrer les messages avec ou sans token pour transmettre en priorité à mon smartphones ceux qui ont un token.
3. Ensuite, pour les nouveaux contacts, il pourrait y avoir un autre token à envoyer par l’expéditeur qui dépende de sa clé privée et de ma clé publique de telle sorte que le serveur pourrait détecter les demandes de messages répétées d'un même expéditeur sans pour autant savoir quel est l’expéditeur ni le contenu du message.
La connexion serveur(de reception) -> destinataire est directe.
La connexion expediteur -> serveur(de reception) est indirecte Tor ou autre juste pour masquer son IP.
Sinon, je suis bien d'accord que Skype, facebook Messenger, whatsapp, Viber, Line, Hangout, and co sont des services où le client se fait plumer de haut en bas ses données persos. Mais je pensais que le sujet était déja arrivé plus haut donc, voila.
J'ai aussi un problème avec le design d'OTR. Si l'une des parties a perdu son token (ex: reboot du device, changement de logiciel client) et que l'autre continue de lui envoyer un message en pensant la conversation toujours en cours, le message sera illisible en face. Donc, OTR me semble vraiment limité à des clients qui peuvent converser en temps réel en continu, ce qui est un peu problématique pour une utilisation asynchrone type "envoyer un message securisé à un correspondant hors ligne"
[^] # Re: ou pas
Posté par tuxicoman (site web personnel, Mastodon) . En réponse au journal Messagerie sécurisée, attention à votre carnet de contact !. Évalué à 3.
Comme dit plus haut, le hash du tel, même salé, c'est faible pour masquer l'identité des communiquants. Mais chacun sa notion de "secure".
Pour revenir au sujet. Je suis d'accord avec toi, le spam est le problème de ma solution.
Pour contrecarrer cela, je pensais :
1. Donner un token aux contacts dont j'accepte les messages. Ce token, envoyé avec les messages à ma destination permettrait au messages d'etre traités prioritairement par rapport aux autres messages reçus.
Les messages d'inconnus (sans token) doivent avoir une preuve de travail, ce qui limite un peu le spam.
2. Recevoir les messages par l'intermédiaire d'un serveur (comme un serveur de mail). Ce serveur pourrait filtrer les messages avec ou sans token pour transmettre en priorité à mon smartphones ceux qui ont un token.
3. Ensuite, pour les nouveaux contacts, il pourrait y avoir un autre token à envoyer par l’expéditeur qui dépende de sa clé privée et de ma clé publique de telle sorte que le serveur pourrait détecter les demandes de messages répétées d'un même expéditeur sans pour autant savoir quel est l’expéditeur ni le contenu du message.
La connexion serveur(de reception) -> destinataire est directe.
La connexion expediteur -> serveur(de reception) est indirecte Tor ou autre juste pour masquer son IP.
Sinon, je suis bien d'accord que Skype, facebook Messenger, whatsapp, Viber, Line, Hangout, and co sont des services où le client se fait plumer de haut en bas ses données persos. Mais je pensais que le sujet était déja arrivé plus haut donc, voila.
J'ai aussi un problème avec le design d'OTR. Si l'une des parties a perdu son token (ex: reboot du device, changement de logiciel client) et que l'autre continue de lui envoyer un message en pensant la conversation toujours en cours, le message sera illisible en face. Donc, OTR me semble vraiment limité à des clients qui peuvent converser en temps réel en continu, ce qui est un peu problématique pour une utilisation asynchrone type "envoyer un message securisé à un correspondant hors ligne"