[118450] in Cypherpunks
Re: (eternity) (fwd) Cypherspace project
daemon@ATHENA.MIT.EDU (Jonathan Stafford)
Tue Sep 28 15:50:32 1999
Date: Tue, 28 Sep 1999 10:38:08 -0400 (EDT)
From: Jonathan Stafford <jestaff2@unity.ncsu.edu>
To: Michael Hohensee <michael@sparta.mainstream.net>
cc: "cypherpunks@cyberpass.net" <cypherpunks@cyberpass.net>
In-Reply-To: <37F0191B.83AFA2F1@sparta.mainstream.net>
Message-ID: <Pine.SOL.4.05.9909281020220.8196-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, Michael Hohensee wrote:
>
> This only works if you can be sure that the server you're talking to is
> not compromised. It also makes it impossible for the server to remain
> anonymous, as is required by the specification on
> http://www.cypherspace.org/eternity-design.html .
I belive the compromised server problem exists in all implementations of
eternity, ie: if I want to find out who is requesting what, can't I simply
run a server (especially given that you know which files they are
requesting).
Your second statement, that servers are no longer anonymous, I do not
follow. I fail to see how the addition of a key pair to all severs would
make them less anonymous, as long as their physical locations were not
discovered. In addition, I envisioned the keys changing regularly, and
that a user would get the keys before making a request.
However, regardless of whether or not my suggestion violates the goals of
eternity, it is easily defeated: A user first makes a broadcast request
for eternity server public keys. Eve adds her key to those that the
client receives. The user encrypts the requested file and client's public
key with the public keys received (including Eve's key, as the client
does not know it is not a legitimate eternity server's public key). The
client then broadcasts the encrypted requests. Eve collects all of the
broadcasted requests, and decrypts them with her key until she finds hers,
thus revealing the requested file.
> Jonathan Stafford wrote:
> >
> > 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.)
> >
>
> --
> Michael Hohensee
>
> "Remember, it takes 42 muscles to frown and only 4 to pull the trigger
> of a decent sniper rifle."
>
Jonathan
--
This message is meaningless and subject to change.
