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
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
