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.

> 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.

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)?

> 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?

To attack this point, you will probably either have to (1) route the request 
randomly, (2) initially route the request to a random location [and then to the 
target], or (3) make a "temporary and only for inserts" peer connection (which 
I guess converts the static target to a mobile target).

> 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.

> announce to that location,

I don't think we can avoid this, as that is a basic operation.

> 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?

--
Robert Hailey

Reply via email to