Matthew Toseland wrote: > Okay, so it's a predecessor sample, a very noisy source, but it will > eventually reveal the originator if one of the attacker's nodes is connected > to it. And the frequency data will also eventually show nodes close to the > originator but not equal to it.
Hmm, good point, I hadn't thought about indirectly identifying the initiator by identifying its neighbours. Could be useful if a darknet node has opennet neighbours... > So suppose we use long lived tunnels. Tagging on long-lived tunnels is > trivial. So we have a high quality sample on every new tunnel. It will be > essential to have multiple tunnels for adequate performance and reliability. Right, but the more parallel tunnels we use, the fewer requests each one carries and the harder it is to tag them. Somewhere between one-tunnel-per-request and one-tunnel-per-node is the optimal tradeoff between number of samples and quality of samples... but I have no idea how to find it. :-) The only rule of thumb I can come up with is that tunnels shouldn't link messages that would otherwise be unlinkable: two splitfiles shouldn't share a tunnel, two Frost IDs shouldn't share a tunnel, etc. > What is the impact of the node creating two parallel tunnels each through one > of its peer nodes which is run by the attacker? If he can link them, there is > still the possibility that they are both from intermediary nodes from another > originator - but this is probably less likely than the node being the > originator, so if we have any long term data we can catch him. If the routes are random, two tunnels that pass through different neighbours of X don't reveal any more information than two tunnels that pass through the same neighbour of X: the probability of the tunnels parting ways at X doesn't depend on whether X is the initiator. (I'll answer the tunnel padding proposal in another email.) Cheers, Michael _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
