Protocole de communication chiffré et décentralisé

[InstinctHack]

Bonjour,

Encore une idée tordue ^^"
Cela rejoint celle du p2p mais en plus originale, ce serais un moyen de communiquer de façon totalement décentralisé (des serveurs ne sont pas exclus pour faciliter le système, mais ils ne DOIVENT pas êtres indispensables)

assertions :
les utilisateurs font un usage correct du système, aucune modification du code, rien.
le réseau bloque de façon aléatoire les communications entre deux utilisateurs.
un utilisateurs est identifé via un id unique et possède un couple de clé public/privé.

Un utilisateur A veut entrer en communication avec un utilisateur B. Il récupère son ID et sa clé publique. Il chiffre son message et lui envoit. L'utilisateur B le déchiffre et lui renvoit qu'il as bien reçu le message avec la signature. L'utilisateur A sait donc que le message est bien passer. Si l'utilisateur B ne l'aurais pas renvoyer, cela voudrais dire que le réseau as bloquer le message, alors A envoyerais le message à tous ses contacts, qui tenterais récursivement d'envoyer le message à B, jusqu'a que B confirme la réception.

Vous trouverez sans difficulté plusieurs problèmes à mon raisonnement.
Mais c'était pour mettre à plat ma petite réflexion, et puis si ça peut en intéressé certains... :p

ps : les problèmes que je voit :
-si le client n'est pas dispo, le message seras envoyer inutilement, faudrais un systeme de ping (mais qui pourrais lui-meme tomber sur le coup de la censure)
-si C est un contact de A, qu'il renvoit le message et demande à ses contacts de le renvoyer, alors si D possède A dans ses contacts, on part en infiniteloop, faudrais demander si les contacts n'envoit qu'un seul exemplaire du message (mais il reste le problème qu'il vont en recevoir des centaines eux O.o )
-Les canaux, on gère ça comment
-le flood si on envoie à un client qui n'existe pas
-et surement plein d'autres

edit : pour le problème des centaines de demandes d'envoi que les contacts receverais, on peux imaginer que le paquet aurais la liste des contacts par lequel il est déjà passer (ça empecherais pas le problème, mais ça en limiterais déjà les répercutions)

edit 2 : bah les canaux fonctionnerais de la meme façon que si le message était bloqué, mais les contacts ne l'enverrais uniquement aux membres du canal ( à partir de ce point, on comprend que les messages pourrais être publiés par n'importe quel utilisateurs du canal et qu'il seras difficile de mettre en place un système de modération du canal)

edit 3 : pour le flood à un client qui n'existe pas, on pourrais imaginer le téléchargement via les serveurs d'une liste d'utilisateurs valides (faut avoir confiance au serveur) et un paramètre pour accepter/refuser de tenter d'envoyer un message à un client qui n'est pas dans la liste

[b0fh]

assertions :
les utilisateurs font un usage correct du système, aucune modification du code, rien.

Hypothèse peu réaliste.

Sinon, comme déja discuté sur irc:

- CF le Triangle de Zooko, sur l'impossibilité théorique de lier des noms user-friendly à des clefs de manière décentralisée. CF aussi Namecoin sur une solution possible mais très chère en terme d'infrastructure pour peu de bénéfices.

Pour le reste, le problème de signer les messages comme ça avec une clef PGP rend le déni impossible, CF OTR pour une solution meilleure mais un peu plus lourde.

Le flooding est une manière peu efficace de communiquer, mais a la limite on pourrait imaginer que pour du chat c'est pas totalement la mort. Peut-être une meilleure manière de faire est d'utiliser une DHT pour stocker la position d'un pseudo, et ensuite lui envoyer directement des données. ça laisse la possibilité d'utiliser un mécanisme tor-like pour masquer sa position, il suffit d'authentifier les entrées de la DHT avec une signature.

Stocker la liste des hops est inutilement couteux, complique le format des messages, et le comportement est difficilement prévisible, en pratique on préfère en général utiliser un TTL. Une autre possibilité est de maintenir un spanning tree sur le réseau (comme fait irc), mais ça ne répond pas bien au churn et ça ne scale pas bien sur les gros réseaux.

[InstinctHack]

Hypothèse peu réaliste.

C'était pour simplifier au début, mais je mettrais en place des protections pour qu'un noeud n'accepte que des messages véritables (pas facile ^^" )

J'en fout de l'user-friendly

Pour le reste, le problème de signer les messages comme ça avec une clef PGP rend le déni impossible, CF OTR pour une solution meilleure mais un peu plus lourde.

Je comprend pas trop les avantages d'OTR à part pour ça http://fr.wikipedia.org/wiki/Perfect_forward_secrecy

pour la DHT, là non plus je vois pas en quoi ça intervient dans mon idée.

la liste des hops / TTL, j'y vois un problème de taille comme tu l'as dis, mais pour TTL, si un nombre de replay limite existe, alors le message ne seras peut-etre pas envoyer par tout le monde.

bref, je continue ma réflexion