On Thursday 01 Nov 2012 18:50:00 Matthew Toseland wrote:
> CONCLUSIONS:
> 
> 00. Without major changes, inserts even on opennet of unpredictable files 
> provide reasonable security assuming the attacker can't create a lot of 
> nodes; the limiting factor is the predictable inserts which are associated 
> with them (forums posts, USK site top blocks etc). Unfortunately we can't 
> quantify how many such predictable inserts are needed to break an identity 
> currently.
> Sadly, downloads are much easier to trace at present.
> 
> 0. Announcement needs fixing desperately, for performance reasons as well as 
> massive security issues.
> (Complex but important, some of it is longer term than others, but much of it 
> needs doing soon)
> 
> 1. We can greatly improve insert security by initial random route. Inserts 
> are slow already, and already have no-cache on the first few hops, so we 
> don't necessarily need any more hops; so the cost should be small.
> (Easy, IMHO this should be done soon)
> 
> 2. For predictable inserts (top blocks, forum posts, maybe even selective 
> reinserts), it *might* be worthwhile to implement rendezvous tunnels. The 
> cost would be relatively small. Also, it is probably useful for gathering 
> security-sensitive data for both the Pitch Black fix and testing announcing 
> nodes. So we probably do need this...
> (Potentially significant project but easier than announcement changes; we 
> should do this within a few months IMHO)
> 
> 3. Connection-age-based routing restrictions may make sense to partially 
> prevent MAST for downloads. The problem is, the download may take longer than 
> any reasonable connection age restriction. In which case we need to either 
> fail, warn the user, or switch to rendezvous tunnels.
> 
> 4. Unfortunately, for downloads, rendezvous tunnels (or even initial random 
> routing) will be rather expensive. We could make them configurable, and the 
> code will probably be shared with that for inserts, so it might still be 
> worth looking at.
> 
> 5. A "proper mixnet" is possible, and likely faster than either rendezvous 
> tunnels or initial random routing, at least on opennet. On opennet, it would 
> use direct connections between nodes on the chain. On darknet, it would 
> probably be relayed internally, so be rather slow, but would still be usable 
> for top blocks, and is much less necessary for unpredictable inserts or 
> normal downloads on darknet. One of the limiting factors is I'd need to do a 
> lot of reading, and probably get some design help after that. For bulk 
> requests, with some work on load management, this could be an actual mixnet 
> rather than an onion network, so more resilient to traffic analysis than e.g. 
> Tor.
> 
> 6. Darknet's primary purpose is robustness IMHO. It should be more anonymous 
> in that most attacks are much harder. In particular, Sybil attacks may allow 
> an attacker to e.g. dominate the keyspace and thus have a good chance of 
> controlling all the nodes on the mixnet path. We still need darknet, and 
> there are many ways we can improve it.
> 
Unfortunately all this is pointless. Opennet is vulnerable to Sybil for the 
simple reason that bandwidth, compute power, and even IP addresses and 
CAPTCHAs, are dirt cheap in quantity.

So what's important?
- We need a lot more seednodes, which means automatic maintenance.
- It would probably be worth making it harder to choose your opennet location - 
provided that it can be implemented quickly.
- Initial random route on inserts.
- Option for initial random route on requests.
- More work on making darknet easy.

Connection-age restrictions are an opennet-only enhancement, so are left out. 
Rendezvous tunnels are probably overkill for now, although I'm not sure whether 
it's okay to send the location-distance probes for the Pitch Black attack in 
plaintext makes sense... depends on how far away the bad guy trying to pervert 
swapping is, he's probably distant...

Attachment: 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

Reply via email to