On Tuesday 23 Jul 2013 19:56:43 Robert Hailey wrote: > > On 2013/07/23 (Jul), at 11:54 AM, Matthew Toseland wrote: > > > 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. > > I don't think we'd need a full toollkit, just some stats on: > (1) the porportionality of long links [and how long they are] (I think we > actually have a target value for this),
Yes, vaguely. Details you may be able to look up, but it is distorted on each node by local load. However, we *do* have statistics on this IIRC. > (2) the probability of being able to insert your node "between" two others > (routing-wise), "Insert your node" ? Meaning what exactly? If you announce to a target location you will get connections close to it eventually, subject to rather weak IP-based limits. It's a circular keyspace, so "between" 0.1 and 0.5 is a lot of nodes - but we don't visit them all. > (3) the average "width" of the network (in number of connections), IMHO the number of hops for a successful request is around 5-7, but an insert (which is much more interesting) will always visit 20+ unless the network is tiny. > > ... and maybe some reasonable assumptions concerning how often an insert > takes place (e.g. once a day?). The easiest target is a predictable reinsert of a very big file. Which would be continuous, and as fast as possible (i.e. slow, as freenet is slow). > > As I see the attack, it would go much like a binary search: > (1) effectively divide the network in half (i.e. most request going from one > half to the other cross one of your nodes), > (2) wait for a predicted insert to cross the tripwire (statistically you'll > catch 1-in-4, so +4 days?) > (3) divide the originating half-address-space in half again (works best with > 50% more nodes [for three partitions]) > (4) wait for another insert (now you'll catch 3/4 of "most"/50% requests, so > that is 3-in-8 requests, so +2 days?) > (5) move the stray partition to subdivide the wedge the request came from > (6) wait for another insert (now at 7/8 address space, so another +2 days?) No, IMHO we can do much better than binary search. That is, to start off we'd like to have nodes (connections? virtual nodes?) distributed across the keyspace, but once we have 20 or 30 actual intercepted inserts (to be quantified), we can overlay the possible locations and get a fair idea where the originator is, and then announce to that location. At which point we will be able to intercept a lot more inserts, and repeat. The information we get is not binary (yes or no): It's a slice of the keyspace within which the originator is most likely to be. > > So under ideal attack conditions (where the target has but one unchanging > peer connection, and the attacker has an as-of-yet-unmeasured number of nodes > at his disposal), with an arbitrarily guessed network size of 10k... it would > take 16 days to zero in on the target; and 18d for 20k, 20d for 40k, etc. Doesn't follow. The major bottleneck will be intercepting enough requests to get the whole thing started. How many nodes he will need depends on how many nodes each insert hits and how often inserts are started. We can safely assume inserts are randomly distributed across the keyspace, because if not, something is broken. > > What is the current network size, anyway? :-) 6K nodes online roughly? > > The problem is, we focus on how easy steps 2/4/6 are, when I'm not even sure > how feasible the rest is. > > Suppose that in the above case I have *more* than one peer connection, and > even just the first hop of an insert is randomized (no random routing code > required; just a random routable peer). Then that 16 day estimate is > effectively multiplied by my number of peers, and becomes 1 year (and the > attacker has to account for the fact that he might be chasing my peers rather > than me, but that wouldn't be too hard... hmmm, maybe if they change). I don't see why this makes any significant difference. If we can get within 2 hops we can certainly finish the job pretty easily - we'll see a sizeable fraction of the outgoing inserts. > > But in terms of the attack cost, we would need to know how many nodes it > would take to "divide the network in half". > > I agree that this would be *significantly* cheaper than connecting to every > node, but IMO the payoff for the attacker is very slow and unsure; what's > more, one could only target *one* source, so it would have to be a high-value > target (IMO). IMHO this could be adapted for requests to trace multiple targets - but it'd be more expensive. > > I would be happy to just ensure that the current code starts inserts at a > random peer. IMHO we need it to start on a random *NODE* globally. That is, route it 5 hops or so randomly.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
