1993-06-01 - No Subject

Header Data

From: Eric Hughes <hughes@soda.berkeley.edu>
To: cypherpunks@toad.com
Message Hash: 81a936d696cdca1ad7ae0708ef1bec9b35615ab5e5eaa5d9b9528892e971f74c
Message ID: <9306012105.AA28350@soda.berkeley.edu>
Reply To: <9306011855.AA08017@toad.com>
UTC Datetime: 1993-06-01 20:31:05 UTC
Raw Date: Tue, 1 Jun 93 13:31:05 PDT

Raw message

From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 1 Jun 93 13:31:05 PDT
To: cypherpunks@toad.com
Subject: No Subject
In-Reply-To: <9306011855.AA08017@toad.com>
Message-ID: <9306012105.AA28350@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


>I don't think the idea of a "virtual server" for anonymity will really
>accomplish much.  

For just plain old reliability in the face of expected hardware and
connectivity failure, it is reason enough.  When one examines intended
such failures, the analysis must be more subtle.

>... you still need to publicize the entry and exit points

Yes.  On any system at all, the portals that guard privacy are public.
For whatever architecture you chose, you still need an actual email
address that resolves down to some physical internet machine to gain
access to that service.

>If the net police determine to shut down the server

Shutting down service is all economics.  It you must simultaneously
shut down even two machines, that is a larger cost that shutting down
one, since there must be coordination.

>one online pretty quickly to replace this one which has been shut down.
>But then the net police can go after that one.  And so on.

Cost, cost, cost.  What is possible and what is fiscally available are
two different things.  Two machines might be in the realm of
possibility, but where is the cutoff exactly?

>You'd get the same effect just by having a bunch of conventional remailing
>servers, only announcing one of them publically, and then having each
>one come online only after the one before it got shut down.

No, there is a single and incredibly salient difference--communicating
the change of address to all those who use the service.  Right now,
this changed information must either end up in people's head, or in
their alias files, or in their scripts.  Wherever it is, it would have
to change.  

This effectively puts a fairly small upper bound on the user base for
such a service, given the characterstic time it takes to communicate
such changes.

Plus, if you want pseudonymous return paths, then you have to make
sure that data is transferred to a new system.

>The hard part in either of these scenarios is collecting more people who
>will run anonymity servers. 

The scenario I envision for virtualized databases is a business
running such a network themselves or in partnership with other
companies.  Doing this all on netcom shell accounts just won't happen.
The hard part here is trying to get someone to pay for the secure
service.

>If the machine itself is inaccessible, the net police will go after
>its feeds, the points at which it connects into the network.

If there is a single point of failure, that's a problem.  This is a
design criterion, not an overwhelming roadblock.

>Look at what happened to Julf.  His machine
>was safe, sitting in a back room of his house.  They went after his net
>feeds instead.

One-point failure!  The politics of the connecting network are crucial
in the long run.  I have a separate message about that.

>The real answer is to publically defend remailers.  

I see no reason why these two approaches are exclusive.

Eric





Thread