On Friday 04 January 2008 01:16, Michael Rogers wrote: > 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...
Opennet nodes won't participate in premix routing. We may build something different, something more like I2P, for opennet nodes. Anyway, attacks involving moving closer to the target are a worry in some scenarios even on darknet - they're something we want to minimize. > > > 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. :-) Okay, so on the one hand, more requests per tunnel means easier tagging (noisier samples). On the other hand, less requests per tunnel means more tunnels and more predecessor samples (more samples). Hmm... I suppose finding the optimal number of requests per tunnel is a matter for simulation? Would it be hideously complicated? > > 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. Well yeah but Frost IDs and splitfiles, and splitfiles and splitfiles, often are linked. So it's not easy. > > > 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. It doesn't? I had assumed they always parted ways at the beginning... hmmm. Can you elaborate a little? > > (I'll answer the tunnel padding proposal in another email.) > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080104/2c9fc452/attachment.pgp>
