On 11/06/14 20:57, Robert Hailey wrote: > 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). Have you read some of the stuff I posted about IP address scarcity? You have some extra complexity but the principle is the same. But IMHO IP based scarcity or even AS-based scarcity is pointless. The best scarcity available right now is manually-created phone-verified Google accounts and they go for $0.10/piece. Not enough to deter any serious attacker.
The only real solution is darknet. The catch is to make that work well we'd need a LOT of users...
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
