On Friday 13 June 2008 13:45, Ian Clarke wrote: > On Fri, Jun 13, 2008 at 6:42 AM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: > > On Friday 13 June 2008 01:16, Ian Clarke wrote: > >> What are the specific threats that we are currently vulnerable to, > >> that this approach will prevent, and how does it prevent them? > > > If the tunnels are short, then it will not result in a large reduction in > > performance, and may enable some significant optimisations which we could not > > implement before for security reasons. > > Ok, so the basic concept is that we are creating relays and then > relaying all requests through them, what is the danger if a relay is > an attacker?
We send out two anchors. If the attacker intercepts both anchors, he can read the data being sent through the tunnel, as well as having two predecessor/location samples. If he doesn't manage to intercept both anchors, but gets the first (short) path, he may be able to do things like introducing a long delay (or a pattern of delays) in each tunnel and see what happens to the request he is monitoring. If he gets only the second path, I'm not sure he'd be able to do anything. In any case if he doesn't get both pieces it will be expensive to identify that the tunnel is related to what he is looking for. > > I hope you are right that this won't slow things down - but I'm > somewhat pessimistic about that. Either way, we need to test > carefully, a more secure but unusable Freenet is a waste of time. It depends on the number of hops. It will have to be enough to give a reasonable anonymity set: ideally we'd have the whole network as our anonymity set, but this requires a number of hops similar to the diameter of the network. Perhaps it is possible to compromise. It would be interesting to implement the rendezvous test I proposed and see what the current value is. Also, the routing enhancement (peers' peers' locations) will probably cut the average path length significantly. Obviously if we have to use a lot of hops this could just be an option for the paranoid, but if it is fast enough it could enable some interesting things. > > Ian. -------------- 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/20080613/ebc81c2b/attachment.pgp>
