On Tue, 14 Sep 2010 14:00:14 -0400, Uriel Carrasquilla wrote: > > they can also in theory replace all of your peers, > > and thus know what keys you are downloading/uploading. > Isn't the content also encrypted? What good are the keys for to lead > back to the originating node?
The main idea is that one can't be sure whether a node is directly requesting a key, or merely relaying another node's request. But if all your peers belong to a malicious attacker, you lose this plausible deniability. (Data is encrypted, but it isn't too hard to map encrypted keys to their actual content.) > >> Given that this would take quite a bit of effort and time, > >> is there the possibility of putting in the network some decoy nodes > >> (honey-pots) that could lead to the violators? > > > Sure, if you don't mind having your node seized :b. > But that would be the idea, lead to a node with no value. > There would be nothing in this node (neither one of the two caches > used by freenet). I don't understand how you think this would work. Moreover, ideally, every node should be an equally tempting "honey pot" -- that is the beauty of a distributed datastore. > > -- you actually (hopefully) know and trust each of your peers, > > unlike opennet strangers. > May be I have watched too many 007 movies, but what if one of your > trusted peers is actually a double agent? That's a good question. Maybe someone more knowlegeable can help flesh out the details, but I recall reading a while back that it's possible for peers to know what is in each other's datastores/caches? (Via a timing attack... faster retrievals imply something exists?) Although one still has plausible deniability so long as you have at least one non-compromised peer, so I'm not sure how meaningful this would be. _______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe