On Sun, 10 Nov 2002 07:56:08 -0800 Oskar Sandberg <oskar at freenetproject.org>
wrote:
>No, this is not going in, unless it is going to be forced over my
>
>kicking and screaming objections.
With a starting line like that, how can I resist replying?
Let's look clearly and dispassionately at the effects of the proxy
code on freenet, being mindful of the actual security goals of
the project...
1) This does not compromize the anonymity of people who publish
documents in freenet. Even if lots of information about routing
was magically revealed, knowing where a document routes to does
not tell you where it was inserted from.
2) This does not compromize the anonymity of people who request
data from freenet. As before, even if lots of information about
routing was magically revealed, knowing where a document routes to
does not tell you where it is requested from.
3) This does not allow you to find out where a document is stored
in freenet. Remember, keyspace is large, and you can only look for
randomly generated keys that don't exist. You can't go looking for
where a particular known document would route too.
4) This does not compromize plausible denyability for node operators
about what their node may store. Remember, this is generating a DNF.
A DNF for a random key may be generated before it reaches a node that
specializes in in similar key, at a node that specializes in similar
keys, or after a node that specializes in similar keys. Where the
DNF is generated depends on HTL. That a node does NOT contain a random
key that does not exist tells you NOTHING about what that node DOES
contain.
5) This does not allow you to probe the network with similar keys
to figure out where specialization may occur, globally. Remember,
keyspace is large, and you can only generate (effectively) random keys.
Trying to generate particular key is like trying to generate a
particular public key.
So, that covers the basics. Lets thing more deeply, what DOES this
allow someone to do? Probing the network for where DNFs get generated
with random keys could give you 2 kinds of information:
a) It allows you to discover freenet nodes.
b) It may allow you to discover highly connected freenet nodes.
Are these bad? Let's think some more...
The first thing (a), doesn't give you anything that you don't get
just by running freenet. Leaving aside node announcements and just
logging what nodes connect to your node, freenet's entire routing
mechanism DEPENDS upon discovering freenet nodes. Freenet nodes do
not hide from each other.
The second thing (b), is more interesting. Does discovering highly
connected nodes in the freenet network make the network more
vulnerable. What if someone found the highly connected nodes and
attacked them? Well, leaving aside the dynamic nature of freenet
and how resisitant it is to losing individual nodes, the surprising
answer to this is that (b) does not give an attacker any sort of
edge. You don't actually have to know the identity of the highly
connected nodes in freenet to attack them. Think about it. As we've
seen, the easiest way to attack freenet is to DOS it with messages,
queries, announcements, anything. What happens when a message flood
hits? Well, the highly connected freenet nodes get the bulk of the
messages routed to them, overload, and go down. Surprise! You don't
need to know where they are to nail 'em.
That pretty well covers things from the technical angle. The
gateway proxy thing in no way compromizes freenet's security and
anonymity goals, and does not render freenet more vulnerable to
attack. It does not undermine the technical goals of the project.
Perhaps more interesting is the philosophical objection. Oscar
objects that freenet is primarily an information storage network,
and using it for other ends dilutes its real goals...
Codswallop! When I originally read Ian's first paper on freenet,
one of the most exciting things was the possiblity of freenet
being used as an entirely new TRANSPORT mechanism for networks.
People have experimented with freenet as transport for all sorts
of things. Right now, people are using freenet things like
message boards and messaging... message transmission rather
than just information storage and publication.
The gateway code is about using freenet as information transport
as well as information storage. I fail to see how this diminishes
freenet in any way...
... I look forward to more kicking and screaming :)
>1) The effect on the opaqueness of the network is real. The network
>already reveals things when data is requested, but we try to keep
>it at
>the minimal necessary level for keeping accurate routing. I'm sure
>that
>one could try to patch over each specific example by making the
>behavior
>more and more complicated, but it betrays the general principle.
>And
>note that this problem is not resolved by making the feature voluntary
>-
>opaqueness is a global quality that effects everyone.
>
>2) Other networks do this better. If you want to protect requester
>
>anonymity for requests to unsafe resources, then there are systems
>that
>are a lot better at it then freenet. A "Crowds" system, for instance,
>
>does not have routing and HTL values that betray nodes that start
>
>requests to others as we do. I believe that cDc's "peekabooty" system
>is
>a Crowds implementation, perhaps you ought to look at that. Mixnet
>
>systems are safer still.
>
>3) Probably most importantly, it undermines the real goals of this
>
>project. Security and privacy for the publisher is just as great
>a part
>of our goals as requester privacy, and encouraging freenet to be
>used
>just as a proxy rather than an information storage network is going
>back
>on that goal. I, for one, have not given up hope that we can make
>
>freenet work at what it actually is.
>
>
>You should have discussed the issue here before you implemented
>this.
>This idea is not new, so you would have had the same response right
>away, and could have saved yourself the time and effort.
>
>--
>
>Oskar Sandberg
>oskar at freenetproject.org
>
>_______________________________________________
>devl mailing list
>devl at freenetproject.org
>http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
Get your free encrypted email at https://www.hushmail.com
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
