From: Ryan Lackey <rdl@mit.edu>
Date: Mon, 12 Jan 1998 11:28:40 +0800
To: Tim May <tcmay@got.net>
Subject: Re: Eternity Services
In-Reply-To: <v03102800b0deac61cffd@[207.167.93.63]>
Message-ID: <199801120324.WAA12254@the-great-machine.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----


> 
> I haven't been following the latest round of "Eternity" discussions. I
> gather that Ryan's efforts are distinct from Adam Back's efforts, which are
> themselves distinct from the seminal Ross Anderson researches (for example,
> at http://www.cl.cam.ac.uk/users/rja14/eternity/node4.html).

Yes, all three efforts are distinct at present.  My "secret" plan is to try
to get a technical design document and demo which are so compelling that
in the end it merges into one Eternity project, though :)

> 
> But Ryan's comments leave me with some questions:
> 
> 
> At 3:11 AM -0800 1/11/98, Ryan Lackey wrote:
> 
> >If I find investors/customers/etc. by March-July 98 for Eternity DDS, though,
> >I'm planning to buy 8 DEC AlphaPC motherboards with dual 21264 processors.
> >Some pieces of Eternity DDS are now being implemented in Oracle for
> >speed of implementation reasons, and other pieces are being prototyped
> >in Scheme (maybe), so even my K6 is getting hammered.  Plus, I'm now testing
> 
> Will these be located in the U.S.? Will their locations be publicized? Will
> any offshore (non-U.S.) locations be publicized?

Hopefully I can allay your fears.

I want the alphas for testing and compiling during the not-yet-production
phase.  They'll be located in one place, subject to being shut down legally
or extralegally.  However, there will be no production data on them, so
there will be no reason to shut them down.  To attack them preemptively would
be less efficient than simply killing the maybe 20 people in the world
who are involved with Eternity development.

I want to have a cluster of machines on which to simulate a working eternity 
system.  I'm trying to develop interconnect protocols which scale to a large 
number of users with the minimum possible trust, no particularly vulnerable
points, etc.  Even me personally owning any substantial amount of machines
involved in a production Eternity implementation while living in the US would
be risky -- I want people to be able to continue to use Eternity even if I
turn out to be a secret NSA agent bent on world domination.  

> [vulnerability of any identified servers]

To this I add the threat of illegal action by enemies of users of the system, 
government or otherwise.  As a result, having *any* of the nodes be locatable
on a network or in physical space is a threat.  Knowing the IP addresses of
all the Eternity servers in the world would be enough to let you flood
them out of existence.

Unfortunately, in order for Eternity to be accessible to the world in some
way, some nodes need to have public logical addresses in some way.  This
opens up a bunch of pathways to attack.

Eternity DDS has market-based protocols to try to hinder these attacks.

> So, the talk about the hardware of all these Alpha servers raises some
> interesting questions.
> 
> I would have thought that a much more robust (against the attacks above)
> system would involve:
> 
> - nodes scattered amongst many countries, a la remailers
> 
> - no known publicized nexus (less bait for lawyers,  prosecutors, etc.)
> 
> - changeable nodes, again, a la remailers
> 
> - smaller and cheaper nodes, rather than expensive workstation-class nodes
> 
> - CD-ROMS made of Eternity files and then sold or distributed widely
> 
> - purely cyberspatial locations, with no know nexus
> 
> (I point to my own "BlackNet" experiment as one approach.)

Yes, that's effectively what I'm trying to do.  Eternity DDS is currently
being developed on the "Athena model" as a bunch of interoperating services
with general utility as well.

During testing, I'm using stuff like Oracle to prototype large sections of the
application.  I've run hundreds of clients off my K6 talking to a couple of 
servers
on my K6.  This does not mean that the production system will involve my k6 in
any way, except perhaps as my client.

I think that Eternity is effectively a massive distributed database, in that a 
filesystem
is a kind of database.  I also think selling just storage is kind of silly -- 
one needs
to take into account bandwidth and computation as well, in order to allow 
people to
do truly interesting things.  With a sufficiently trusted JVM, one could 
execute some subset
of java code remotely fairly securely.  I'm planning to have interfaces to the 
Eternityspace
which make it look like a massive web server, a massive traditional database 
server, a filesystem,
ftp, email server, etc.  This helps functionality and security.

The design is a compromise between security and efficiency.  In many cases 
being
distributed is good for both, but in at least two areas, trying to make E-DDS 
distributed is making it less efficient.  I forsee that the initial limited
production system will have a nexus in that the auction market will probably
be run by my organization through a geographically-dispersed network of 
machines
with byzantine fault tolerance.  I also forsee an initial small number of nodes
interfacing Eternity DDS to the world (via the web, database protocols, 
filesystem
protocols, etc.).  While there will be encryption between those servers and 
their
clients, they will be targets for attack -- however, there are a bunch of 
techniques
for making them ephermeal, some of which you have mentioned.
> 
> It may be that the architectures/strategies being considered by Ryan
> Lackey, Adam Back, and others are robust against the attacks described
> above.

I hope so.
> 
> Basically, if the Eternity service(s) can be traced back to Ryan or Adam or
> anyone else, they WILL be subject to court orders telling them to produce
> certain files, telling them to cease and desist with regard to certain
> distributions, and so on. Even raids to carry off the entire file system
> for analysis will be likely.
> 

I hope to leave the country before Eternity DDS goes public.  I think raids
on US sites, or unprotected foreign sites, are highly likely, legal or 
otherwise.
I don't believe any government will provide any real defense for an identified
Eternity server or nexus or involved person, once it starts being used for
corporate espionage, money laundering, political activism, etc.  The only 
defense
is to make sure the collateral damage from taking it out is high enough that 
they
won't, like an inoperable tumor (a 10mm does a good job of removing most 
individual
cancer, but sometimes killing the patient is unacceptable)

Hopefully, the designers of the first production Eternity service can make 
themselves
irrelevant enough to not be worth killing, and/or difficult enough to kill 
that the
collateral damage from killing them would be unacceptable.

> It is also likely in the extreme that a working Eternity service will
> quickly be hit with attackers of various sorts who want to test the limits
> of the service, or who want such services shut down. Thus, expect all kinds
> of extremely controversial material to be posted....granted, this is a
> "reason" for such services, but see how long the system lasts when it
> contains child porn, Scientology secrets, lists of CIA agents in Europe,
> copies of Microsoft Office for download, and on and on.

Yes.  I'm designing for the worst.
> 
> And even a decentralized, replicated system will of course still expose the
> owner/operator in some jurisdiction to his local laws. (As Julf was exposed
> to the laws in his country, and that was just the tip of the iceberg.
 
I'm planning to move to the most laissez-faire location possible.  I also want
to make myself irrelevant once the system enters production (which does not
necessarily mean I won't try to get rich, just that if someone corrupts or
kills me it won't make any difference to the operation of the system).

> Eternity nodes must not be identifiable, and their locations must not be
> known. Anything else is just asking for major trouble.

I agree with you 100%.  There are technical considerations which come into play
defending eternity nodes from TA, other corrupt nodes, etc., but they are in 
the
main solvable.  The borders of the eternity logical network become exposed, 
but it
is possible to push those borders far enough out that it becomes the 
responsibilty of
other unwitting parties to shut them down.

My design goal is truly distributed and truly secure.  In order to take out 
eternity, I
hope to make it necessary for the attackers to take out the Internet, 
something even
overly communist regimes are unwilling to do.

I think Adam Back's Eternity implementation mostly meets the "lightweight nodes
which no one cares about" in theory, and if his assumption that usenet will not
be attacked is valid, it has met the "unacceptably high collateral damage"
criteria.  I'm somewhat unsure of that assumption, though.

Plus, the central difference between Eternity DDS and the other two Eternity
designs is that market forces will be used to give people an incentive to 
break the
law by running Eternity DDS servers secretly in Burma (both internal storage
nodes and throwaway interface nodes).  I think market forces are the only way 
to
get people to implement a large enough Eternity logical network to provide
protection from a concerted attack.

> 
> Comments?

More discussion would be great.  I think everyone agrees on the basic 
requirements
for Eternity implementation -- it's just a question of which compromises one 
must
make to technical expediency, as well as advanced technical methods one can use
to minimize those compromises.  

[Pseudo-ob-non-crypto: I apologize for sof.mit.edu's web server being dead for 
a while.  It
managed to wedge itself quite nicely, and I didn't find out about it until 
someone sent me
mail.  Again, I'm putting as much documentation as I can up on 
http://sof.mit.edu/eternity/]

- -- 
Ryan Lackey
rdl@mit.edu
http://mit.edu/rdl/		



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNLmM16wefxtEUY69AQGobAf/c8PleA2nc4a17HikOGbevX6l/hJzZCf1
ZwwSM2X9jT0Jbg3FhGBt4aj2mRSDDYA9C96StMl2tNZlIQf4PKtyIt2mysh4dO1L
OsmAgemdqh9oHSEHalSDasGURSdzWBCuMctgcwT2BA+zWmWNILo4pw8ePgH2Hc2e
tTmJpfrALMU2pOjkeQ3R6OPOVRPc4JRz/XpRLcFbwEy2DahVzc1ICjfdO7II/qhd
3UJtpxF+mKBrSLVfCINrkg6kXR2c9aL4bFBm5ZoINADH/sPSqghzgNRE9RLLpvqD
2bZmmzUUAgoTNhSEqHk0xl4VaRmVBf1JntetTmWBe1h2b7rh/Anr5w==
=0O/n
-----END PGP SIGNATURE-----