On Friday 04 January 2008 00:37, Michael Rogers wrote: > Matthew Toseland wrote: > > The tunnel is constructed onion-style during the request's forwarding. The > > return tunnel likewise. There is no tunnel construction time. > > Ah cool, I see what you mean now. > > >> It doesn't matter that most of the samples are wrong - all > >> that matters is that the initiator is more likely to be recorded than a > >> random node (or a random member of the cell). > > > > Ok, this is possible, although slow. Is it fatal? How much data does the > > attacker need? > > Hard to say in general - it depends on an awful lot of variables. But we > know that increasing the number of linkable tunnels increases the number > of samples the attacker can collect.
One classic strategy from mixmaster etc is to have a long delay at each step. We could do this for the more sensitive requests. The objective would be to send on the requests (more likely inserts) in groups big enough to likely contain requests from all the nodes in the cell. > > >> We're caught in a cleft stick here: algorithms that give a universally > >> agreed score for each node are vulnerable to Sybil attacks [1], but if a > >> node's score depends on who evaluates it (eg the flow-based algorithm > >> you sketched above) then how do we agree about which nodes to ignore? > > > > Well can we just use it from one node's perspective? When I last looked into > > it that looked very risky. > > Do you mean every node calculates the trust thresholds from one node's > perspective, or each node calculates them from its own perspective? How about a node can't join the cell unless its credibility with all or most other members is over some value? > > Cheers, > Michael
pgp8YbEXuxGZi.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
