On Tuesday 23 Jul 2013 16:30:57 Robert Hailey wrote: > > On 2013/07/23 (Jul), at 5:08 AM, Matthew Toseland wrote: > > > if I can't beat MAST I'll go mad. > > Is this "Mobile Attacker Static Target"? I was not able to quickly find a > past thread with such a title.
Mobile attacker source tracing. Documented on the mailing lists sometimes, FMS etc, and there is a page on the wiki that is reasonably complete IIRC. > > > MAST: Listen for a predictable request/insert, triangulate roughly where > > the originator is on the network based on the requests you receive, > > announce to that location, repeat until you have the target. Cheap. Really, > > really cheap. > > You've probably already done this, but for purposes of discussion (or my > understanding), maybe we can break down the possibilities. > > > MAST: Listen for a predictable request/insert, > > Can we narrow the field to inserts? or at least judge them as separate > problems? AFAICS, triangulating predictable GETs (a noisy operation, like > watching for an SSK update) is far different from trying to catch a PUT (a > quiet single-shot event), trying to solve them both with the same mechanism > *will* make you go mad. Inserts are much more valuable most of the time. This is an assumption we make, which is sometimes wrong, but it's reasonable given that Freenet is a storage network. Fetches are harder because there might be multiple people fetching, but they're easier because there's no way to prevent the keys being predicted in advance. Whereas for inserts, the best defence is to insert as SSK, i.e. with random keys. Unfortunately you need to insert some predictable keys sometimes (SSK top blocks, chat posts, and reinserts). > > IMO the best way to avoid predictability with GET ops is top-notch caching & > cache invalidation, and I seem to recall a promising discussion of a 2-step > "insert-then-reveal" mechanism for the top insert block (the only one that is > predictable. Is that enough to kill the predictability, or did we find that > you have to protect every insert (not just the top)? It's not a bad idea, but it's not published, and its effect is unclear / hasn't been simulated or modelled thoroughly. Whereas proper tunnels there is lots of stuff on. Also, it's quite expensive. > > > triangulate roughly where the originator is on the network > > And by that, I suppose you mean "which peer you received the request from" > tends to point towards the originator? Yes. The attack reached you, and it's for a target location. You can deduce that it's most likely to come from the part of the keyspace where it would have been routed through you. This is relatively simple (the circular keyspace is a problem), and you combine it between lots of requests to get an increasingly accurate picture of where the inserter is likely to be. > > To attack this point, you will probably either have to (1) route the request > randomly, This is the best option. > (2) initially route the request to a random location [and then to the > target], or This is easier to trace than random routing. > (3) make a "temporary and only for inserts" peer connection (which I guess > converts the static target to a mobile target). Not sure what you are talking about here. You mean instead of bundles as tunnels, you want to random route to set up a connection, and then transfer the data, avoiding the performance penalty of relaying it through 5 random nodes? Not a huge difference given that a normal insert visits 20 nodes - and the recipient knows (passively) exactly who is requesting/inserting the data, and what they are inserting/requesting (even better than if they're a peer in the current network). Which may be bad as you'll probably need multiple such connections for performance reasons. > > > based on the requests you receive, > > Can we make it unlikely that an attacker receives a request? In a healthy > network that would already be the case, so I presume that the efforts to > secure opennet address this part. The problem is if you're doing a big reinsert there's a good chance he'll receive it. He can increase this linearly by getting more connections. > > > announce to that location, > > I don't think we can avoid this, as that is a basic operation. I'm not sure. If we can impose some sort of cost on identity creation, and then create the location randomly, we can make this more expensive. > > > repeat until you have the target. > > I get the impression that there is more theory in that fragment than is > initially obvious. > > You are presuming (perhaps correctly) that the attacker has a semi-continuous > stream of requests that he can trace back, and that at each location in the > network (that he chooses) he has a high probability of being somewhere in the > path of these requests. Really? Right, he needs enough requests initially to get a target location that is likely to be closer to the originator than he currently is. On a really huge network, he'd need more connections, but this is still much cheaper than connect-to-everyone. Note that he can correlate data from requests hitting different nodes/connections with different locations. We haven't quantified this. Maybe we should, but it doesn't seem a good use of scarce resources to implement a toolkit for an attack that we're not sure how to beat! At least not if I do it.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
