On Monday 22 Jul 2013 16:57:35 Ian Clarke wrote: > On Mon, Jul 22, 2013 at 9:32 AM, Matthew Toseland <t...@amphibian.dyndns.org > > wrote: > > > Since Eleriseth announced he was leaving and we should focus on > > speed/usability, then opennet security, and only then darknet, I have been > > looking into options for securing opennet, and discussing this with various > > people. > > I agree that speed/usability should be the top priority (although obviously > not the only priority).
There is plenty we can do to improve both. Including on darknet. > Most of the proposals below are directly contrary > to usability - we need to encourage people to contribute to the Freenet > network, not punish them for it, nor make them jump through unnecessary > hoops. We need to find solutions that won't make it even more difficult to > contribute to the Freenet network. There are none IMHO. Our options for significantly better security are either: 1) Make darknet easy and fast, and hope it doesn't take the rest of the century to reach critical mass, or 2) Make opennet secure (meaning considerably less easy) > > The main attacks here are: > > - 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. > > To the extent that this is feasible, routing a request randomly on its > initial hop, perhaps with a bias towards nodes that are further from your > node's location, should make this considerably more difficult. We can route randomly for several hops, with only minimal performance impact (especially on inserts). We can bundle a bunch of related inserts together and route them as a block for several random hops. Combined with some means to make it hard to choose locations to announce to, this makes MAST somewhat harder. But it has no effect on the second attack. > > > - Surveillance: Connect to every node, log all the inserts for a month > > (freenet content doesn't last long if not requested). Connect it to > > announced content. Surprisingly cheap, given our relatively low bandwidth > > usage per peer etc, and it will become cheaper per node as the network > > grows because bandwidth (and everything else) gets *really* cheap in large > > volumes. This is a Sybil attack: The only way to beat it is by using some > > sort of scarcity. > > We could have nodes detect this kind of behavior since it would be somewhat > weird - a bunch of inserts coming from the same node, etc. Essentially a > heuristic "bad behavior" detector that cases nodes to be blocked. All the attacker has to do is connect to lots of nodes. The simplest implementation is not detectable at all (short of dubious IP scarcity etc), but it requires a relatively large number of nodes. Some of the hacks that might be used to retain connections to the right set of nodes *might* be detectable. Maybe.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
