On 2014/06/11 (Jun), at 9:51 AM, xor wrote: > How can we make the resource of > Freenet nodes / user identities / pseudonyms scarce enough to ensure that 1 > attacker cannot pretend to be 10000 entities? > > ... > > There seem exactly 3 solutions to it:
There are others, maybe even some not-yet-imagined... and others that may be wholly impractical. Your key point is too true! Find the scarcity! I suspect that a good solution might have to be aware of border gateway routes, or maybe have a built in traceroute function... operating on the scarcity of "routes" between networks, or the "density" of ISP links to datacenters versus consumer ip addresses. Even if we discover a great theory to isolate a good scarce resource, building it into an emergent system will likely be an order of magnitude harder.... and likely to be a moving target (e.g. with network reorganization/upgrades, or the IPv6 protocol change, etc). Perhaps it would be possible to use human decernment? - Suppose each node had a SSK that they regularly updated... much like the ARK record, but we can't use ARK for this case... maybe closer to a date-based-redirect... basically a way for any node to verify that another node is (1) recently online [unspoofable date], and (2) has taken the trouble [accrued time/effort of inserting] to maintain a current record [because it exists]. A weak proof-of-work, but something to build on... Further suppose that for each active (or recent) opennet connection, but at the node's leisure, a traceroute will be performed... usually giving us a list of IP addresses between us & them (sometimes it doesn't work)... from that array, we discard any common prefixes to other peers that do not claim to be in the same subnet (which is to say, "how we get to the internet"; and specifically excepting the easier-to-detect "same subnet" case), and the remainder we insert at a predictable-but-not-scannable address [i.e. hash(ip_address)] our verifiable proof-of-work... [I guess it would have to sign the hash or ip_address, so other's can't use our proof]... in such a way that inserts to the same address "accrue", and are fetchable in-total (more-or-less, not very important). What we then have is something good & bad... On the good side, any node can reason: (1) how similar and how likely to share a bottleneck two peers will be... (doesn't do much for sybil, given multiple datacenters, but maybe..), (2) at any particular point in the chain (keeping in mind that a sybil agent might own network hardware) how many "connections" they have (*VERY* nice for sybil) On the bad side, (1) it may be impossible to mechanically decern the difference between a core internet router and a sybil network (I'm hoping the dropped route prefix would fix this), (2) it might not help against short-lived connections (a mobile attacker, or churning sybil?), (3) there would now be an easy test to see if a given ip address runs (or routes to) a freenet node... without even sending them a packet. However... We could then probe for... that is gather, all this weight data, graph it, and perform research against it to (1) know if we at any particular time we are under a sybil attack, (2) notice any massive influx of nodes & at what point, and (3) develop an effective countermeasure by tweaking [for example] the above prefix dropping algo, or whitelisting core routers, etc... as the hashed ip address should be safe enough to publish, and meaningful enough for interested nodes to match against. For such research, we could even include the hash of the "next hop" and/or "previous hap", so we can build a graph or get a directional qualification (how many connection *into* versus *out-of*)... if that's even meaningful... - For a little more work, we could require that the original ssk have a list of all of it's "votes"... *hashed-again* (maybe several times, maybe even salted) so that one cannot easily walk an id back to it's set of connections... that would (1) prevent one proof-of-work from being used for an arbitrary number of votes, and (2) let us give each vote a weight inversely proportional to number of entries the id validates. - Yep... it would be a lot of work to even *begin* to get a handle on sybil !!! ... and it's a bit inverted, as you need to use the high-level functions of the network (get/insert) and operating system (traceroute) to validate a low-level function (connection). -- Robert Hailey _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
