[118539] in Cypherpunks
Re: (eternity) (fwd) Cypherspace project
daemon@ATHENA.MIT.EDU (Michael Hohensee)
Fri Oct 1 13:15:25 1999
Message-ID: <37F4B1F9.3E0552D8@sparta.mainstream.net>
Date: Fri, 01 Oct 1999 09:07:05 -0400
From: Michael Hohensee <michael@sparta.mainstream.net>
MIME-Version: 1.0
To: "cypherpunks@cyberpass.net" <cypherpunks@cyberpass.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: Michael Hohensee <michael@sparta.mainstream.net>
Jonathan Stafford wrote:
>
> 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).
Not necessarily, since you don't really know what's being requested, and
since a blob is only a *part* of a file, it's possible to spread it out
over multiple systems. The cypherspace spec. works under the
*assumption* that some of the servers may be compromised, since anyone
can run a server. The nice thing about it is that cypherspace works to
protect server anonymity even if some of the peer servers are
compromised. The only flaw (from my point of view) is that users
retrieving information can be traced as things currently stand.
> 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.
The idea laid out in the cypherspace specification was to make it
impossible (or at least difficult) to determine where each blob was
retrieved from, to make it impossible to prosecute the server operators
for supplying possibly illicit materials. If you assign a keypair which
lasts for any significant length of time, an attacker might use traffic
analysis to trace the server's location on the network, which is a hop
skip and a jump from finding its physical location.
> 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.
I'm not sure that I understand what you're getting at here. It looks
like all that Eve would have is the ID of the requested blob. There
doesn't seem to be any point in encrypting the request for the blob as
it travels over the network, since as you point out, any server could be
compromised. I don't really understand what you'd gain by expending
bandwidth and cycles to perform the above...
You might want to go back and read the specification mroe carefully.
The nicest thing about it is that it will function correctly even if
there are many compromised servers. Each blob is encrypted, and the
servers lack the keys, so we don't have to worry about data compromise.
I'm just ranting about attackers assembling lists of dissident elements
by keeping a log of who's requesting which blobs. :-)
--
Michael Hohensee
"Remember, it takes 42 muscles to frown and only 4 to pull the trigger
of a decent sniper rifle."
