[118430] in Cypherpunks
Re: (eternity) (fwd) Cypherspace project
daemon@ATHENA.MIT.EDU (Jonathan Stafford)
Mon Sep 27 20:24:33 1999
Date: Mon, 27 Sep 1999 19:57:48 -0400 (EDT)
From: Jonathan Stafford <jestaff2@unity.ncsu.edu>
To: Adam Back <adam@cypherspace.org>
cc: eternity@internexus.net, cypherpunks@cyberpass.net, I.Brown@cs.ucl.ac.uk
In-Reply-To: <199909272010.VAA08998@server.cypherspace.org>
Message-ID: <Pine.SOL.4.05.9909271948440.9776-100000@eos00du.eos.ncsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: Jonathan Stafford <jestaff2@unity.ncsu.edu>
On Mon, 27 Sep 1999, Adam Back wrote:
>
> 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
>
<snip>
> 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? :-)
<more snip>
I believe this problem might be avoided by doing the following:
Each eternity server has a public and private key pair. Prior to
requesting a file, the client encrypts the requested filename and the
client's public key with the server's public key. Then a request of the
file is made, with the GET passing the encrypted information. The server
proceeds to decrypt the GET request and then return the requested file
encrypted with the client's public key. (It is imperative that something
other than just the filename be encrypted in the GET otherwise all
requests for a specific file would appear identical, thus defeating the
whole reason for this goofy scheme.)
Jonathan
--
This message is meaningless and subject to change.
