On Sunday 30 December 2007 13:27, Michael Rogers wrote: > Matthew Toseland wrote: > > If you route randomly on each hop I'd > > expect to on average not get very far, because *most links are short links* > > on a small-world network. > > Yup, it's counter-intuitive because of clustering but small world > networks do have fast mixing times, ie short random walks will quickly > take you out of your local neighbourhood.
Interesting. > > > On the other hand if you choose a random location > > and consistently route towards it you should have an equal chance of ending > > up anywhere on the network. > > Almost equal - the probability of ending up at a node is proportional to > the amount of keyspace it controls, which is somewhat unevenly > distributed even in an ideal network. Sure. > > > The catch is that if you route lots of requests > > to different random locations, and the attacker can connect the requests, he > > can gradually narrow down the locations you could have started in. > > True, and Borisov doesn't address this problem (which IMO is a major > one). As you know, my proposed solution is to reuse the same random path > for as long as possible (tunnels). Right. Despite my other posts, I'm not totally against tunnels, perhaps after premix routing. But IMHO we will need quite a few of them for good performance / reliability, even several for a single request group. > > > On a cell of 10,000 nodes, if on > > average each node goes down once a day, and this impacts on 10 other nodes, > > we have ~ 100,000 messages ... perhaps hundreds of megabytes, so it may be > > that cells this big are feasible. > > There's a tradeoff here: large cells provide a large anonymity set if > the attacker's outside the cell, but they make it more likely that > there's an attacker inside the cell who can attack key distribution etc. Sure, but inside the cell it's harder to attack than outside it, surely that is the whole point? Tor, I2P, Mixmaster and other traditional onion routers (apart from spanning tree impl's) use a whole-network cell. > > 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/20080103/4fdda461/attachment.pgp>
