[118427] in Cypherpunks
(fwd) Cypherspace project
daemon@ATHENA.MIT.EDU (Adam Back)
Mon Sep 27 17:41:09 1999
Date: Mon, 27 Sep 1999 21:10:57 +0100
Message-Id: <199909272010.VAA08998@server.cypherspace.org>
From: Adam Back <adam@cypherspace.org>
To: eternity@internexus.net
Cc: cypherpunks@cyberpass.net
Cc: I.Brown@cs.ucl.ac.uk
Reply-To: Adam Back <adam@cypherspace.org>
Ian Brown & I have some thoughts on an eternity service design on the
web at:
http://www.cypherspace.org/eternity-design.html
Below [1], [2], forwarded with permission, are some comments from
Michael Hohensee on this design.
Other comments on design? Comments on Michael's comments?
Adam
[1]
======================================================================
Date: Sun, 26 Sep 1999 13:08:33 -0400
From: Michael Hohensee <michael@sparta.mainstream.net>
To: adam@cypherspace.org
Subject: Cypherspace project
Hi. I liked reading http://www.cypherspace.org/eternity-design.html.
You appear to describe an effective means of constructing a distributed
censor proof network storage system, but there appears to be a DoS
attack that it remains vulnerable to. If I understand things correctly,
there is a way for an attacker with the ability to sniff arbitrary
points throughout the network to make cypherspace too risky for anyone
to use for receiving publications of sensitive information.
Consider the case where A possesses a file X. A wants to make X
publicly available to a specific B (possibly a group of people), and it
is desired that no third party (or anyone within B) can determine who is
reading X. To do this, A distributes the X over the eternity network.
We can assume that the decryption keys for reading X have already been
securely transmitted, and that A was able to get X onto the network
without being noticed by Eve's sniffers.
Now suppose that Eve has compromised the _client_ of someone who has
been reading X. That is, Eve knows that some b in (A U B) has been
reading some Y, and that Y is made up of certain blobs. Note that Eve
can learn this without b's knowledge by logging all blobs which travel
along the wire to b's node on the network if b is at or very near to the
terminus of the network (b's on a dialup to his ISP, or is a very small
ISP). Now Eve can determine who else is likely to be in b's group by
comparing the list of blobs that b requests with those that other people
request. If at some point, Eve makes a physical raid on b, and manages
to learn that Y=X, she now has a list of people who have also been
reading X with high probability, and can proceed to bust others in B at
leisure.
The net result is that if there is any risk that someone in B may be
compromised by Eve, no one in B will dare request the blobs containing
X. Thus no one will dare use cypherspace for publication or anonymous
group communications -a rather effective DoS attack.
The only way around it, so far as I can see, would be for the clients to
anonymously broadcast their GET requests over the entire eternity
network, and for the servers to broadcast the blobs to every machine on
the world or possibly regional network.
It's still useful as a remote distributed filesystem, since all you have
to do to disassociate yourself from X is destroy the keys for decrypting
the blobs, rather than the data contained within the blobs. It's only
in groups of 2 or more that this point source of failure occurs.
Am I correct, or have I missed something obvious which makes my above
analysis invalid? :-)
Regards,
- --
Michael Hohensee
"Remember, it takes 42 muscles to frown and only 4 to pull the trigger
of a decent sniper rifle."
[2]
======================================================================
Date: Sun, 26 Sep 1999 13:18:10 -0400
From: Michael Hohensee <michael@sparta.mainstream.net>
To: adam@cypherspace.org
Subject: Cypherspace (more)
Ack. I forgot to tack this into my previous message:
The attack outlined in the last message might be countered if every
client was also a long term server, and if blobs were routinely
exchanged (and deleted, after exchange?) between clients and servers and
from server to server. The value of Eve's list of blob-readers can be
made arbitrarily small by increasing the frequency of blob transfers.
It's especially important for clients sitting at the edge of the
network, since they're otherwise unlikely to request a significant
amount of chaff blobs unless they're always on. This will of course
cost bandwidth. Perhaps each blob can be marked with a 'sensitivity'
field, which determines how frequently that blob is to be exchanged,
taking ones local network availability into account.
--
Michael Hohensee
"Remember, it takes 42 muscles to frown and only 4 to pull the trigger
of a decent sniper rifle."
