On Monday 18 May 2009 03:12:06 [Anonymous] Anon User wrote: > > I noticed on the website that you're working towared 0.8 being > released later this year. will you be including premix (onion) > routing in this release?
Maybe. It will probably include Bloom filter sharing. This may or may not require encrypted rendezvous tunnels. This is the latest incarnation of the premix routing proposal; classic premix onion routing is poor in that it costs a lot of hops and gives a very small anonymity set. Encrypted rendezvous tunnels are a variation on a proposal in a paper; basically we send out a series of anchor requests, which are random routed for some distance and then approach a particular location, each has a part of a secret, and when enough of them come together on a single node, we put them together to create an onion-like encrypted tunnel through the shortest route. We may however be able to safely implement Bloom filter sharing with only some changes to caching - specifically, we would not cache until the HTL reduces below some threshold. This solves datastore seizure attacks, although it is (still) possible to try to find the circle of nodes several hops away from the originator where data was cached when the HTL did fall below the threshold. We would probably need to tweak the HTL parameters. At the moment, HTL is at the maximum (10) for an average of 10 hops (10% chance of decrementing to 9); this is too much if we are not caching the returned data, we would probably change the average path length to say 2 (50% chance of decrementing), and increase the max HTL to 18 so there is the same number of hops overall. The current thinking is that requests would be cached at HTL 16 or lower and inserts at HTL 14 or lower. We will try to ensure that 0.8 is no less secure than 0.7. Bloom filter sharing should improve performance considerably, but clearly has the potential for security issues; we are essentially letting our peers know what is in our datastore! But IMHO this is a risk that can be managed - and there are some security benefits, e.g. if you can fetch all of a file from your trusted darknet peers then an attacker who isn't one of them doesn't get a look in. The bulk flag may be implemented on the 0.8 timescale, it would improve performance noticeably and might make requests slightly more distinguishable (in that you have a flag indicating whether the requestor wants low latency or high throughput); this isn't significant IMHO when considering serious attacks. MHKs (top-block redundancy) will definitely be in 0.8, and have no security impact afaik. Hopefully we will also include auto-update of plugins over Freenet, which should improve security for most people, and make Freenet work better in hostile environments. > > If not, when do you expect it to be implemented? If it's not in 0.8 it should be in 0.9. Encrypted tunnels are not inherently a really difficult feature, but they will likely require a great deal of tuning and similar work related to security/performance tradeoffs. And tunnels will likely cost a significant amount of performance. They may only be enabled at MAXIMUM security level; there would be little point at NORMAL as Sybil is just way too easy on opennet. Of course, by that logic, since almost nobody uses darknet, tunnels may never happen ... But we have 6-8 months' funding from Google, hopefully we will be able to improve security over this period as well as performance and usability.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Support mailing list [email protected] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[email protected]?subject=unsubscribe
