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

Reply via email to