(eternity) Re: Eternity Services

[Ryan Lackey]

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


> 
> My comments below are not meant to cast doubt on Ryan Lackey's scheme, but
> just to raise some questions.
> 
> I am surprised, I have to admit, that Ryan is talking so much about raising
> money, getting investors, etc., when no _working model_ of his scheme has
> been deployed for people to play with, find weaknesses in, etc.

No working model has been deployed by me as of yet.  However, most of the
components are "solved problems", with existing working models.  Worst case,
it would be possible to accomplish equivalent functionality by linking
these by remailers and hoping no one shuts down the remailers.
> 
> (In comparison to, say, remailers, which have existed for more than five
> years now, with literally thousands of articles--some good, some
> bad--written about them in all of their various facets. Even specialized
> lists for remailer operators, Mixmaster-type remailers, etc. And yet there
> have been no serious calls for investors to pour money in.)

I believe no one has seriously called to pour money into remailers because 
there
is no money to be made from them, and making them commercial exposes them to
additional pressure and liability, not because they are technically poorly 
designed.
> 
> Frankly, in reading Ryan's summary, including assertions like "In my
> system, no one knows (ideally) who is actually storing the data, only those
> on the edges of the system (who will hopefully only be known by a logical
> address)," I find no real discussion of the *core idea*, the _reason_ his
> data base is in fact secure.

It's not a database.  A technical design document describing it, security
assumptions made, and implementation guidelines has been under development.  I 
have
been working on small demonstration components only in order to test ideas -- I
have identified technical problems which are essential to an Eternity 
implementation, and I have been looking into literature for solutions.  In
some areas, no good solutions exist in research, so I've been trying to
find technical solutions.
> 
> (I apologize if a full discussion is contained in his earlier documents.
> Even if his earlier documents had a fuller description, there has certainly
> been an almost complete lack of discussion of his system here in
> Cypherpunks. Given the additional complexitities an Eternity type data base
> has over something as conceptually simple as a remailer, the lack of
> discussion is not confidence-inspiring that Ryan somehow got it all
> right.....)

A full discussion is included in a document which has not yet been released.  
It's
not finished, even in draft form.  Classes and leaving the country to talk to 
people
and work on a side project got in the way of finishing it.  Once a draft is 
done,
I'm planning to release it to a small set of people, get their comments, then
finish the demo and send it to the cypherpunks community, with a pointer to the
demo.  I do not want to release a half-finished draft for fear that then 
progress will
slow to a standstill on the unfinished parts.

> 
> Anyway, I can think of all sort of threat models, and ways of (maybe)
> attacking any system of linked machines I can think of, except ones using
> message pools (which is why I'm biased in favor of Blacknet, I suppose).
> 
> (The motivation for Blacknet was to a) demonstrate message pools, b) show
> that anyone could be a node, c) build a system where the links between
> nodes are all of the traffic in "speech space," and that so long as
> encrypted messages could be posted in speech space (Usenet, boards, etc.),
> then the system could not be shut down. Basically, to stop Blacknet one
> would have to ban remailers in all jurisdictions, or ban speech coming from
> certain jurisdictions. Otherwise, it's too distributed to stop.)

I don't believe in the protection of being in "speech space" vs. being
in network space as substantially different.  Extralegal means will be
used to shut down servers in either case, if it is sufficiently important
to the attackers.
> 
> (Note: But Blacknet has long latency, derived from its "speech"
> underpinnings. There is the temptation to go to faster links, to move away
> from speech space into traditional network links. But this reduces the
> number of nodes and links, and makes an attack on the reduced-but-faster
> network no longer equivalent to interfering with free speech. A
> technological win but a political lose.)

It does not necessarily reduce the number of nodes and links (it may for
a given amount of traffic).
> 
> Until we see a mathematical model--forget the details of implementation,
> the epiphenomenal stuff about Oracle, AOLServer, Alphas, and K6s!--of how N
> distributed nodes store incoming files in such a way that the goals of
> Eternity can be satisfied...
>
Yes, a mathematical and technical model is critical.  However, certain
technical questions not directly related to security are easiest to solve by
experiment.
 
> (And we need to discuss in more detail just what the goals can
> realistically, and economically, be.)
>
Yes, this is true.  I've prepared a list of goals and assumptions -- I will
post them at some point in the near future.  Debate over them would be more
fruitful than any technical debate at this point.
 
> There are a bunch of issues which come up, motivated by Ryan's comments
> that he already has the design of a file system in mind:
> 
> - why won't all machines in the network in Country A simply be shut down,
> regardless of whether the Authorities can prove which machine in particular
> is storing the banned material?

If every single machine in country A is shut down, then Eternity access to that
country fails.  This is why it is essential that all machines involved
in the network retain anonymity, both from users and from untrusted other
nodes.  Several methods exist for this, including a cellular structure, 
anonymous
writing by using remailers or other technical means, etc.
>> 
> - given the problems remailer networks have to deal with, with traffic
> analysis and correlation analysis (an area we have alluded to but not done
> serious work on), why would not the same methods be applicable to tracking
> movements through the system Ryan is apparently proposing?

Components of the system will take their own security into account when pricing
service.  It won't necessarily be linear.  Since they have their own security 
in
mind, they will not willingly send a file which will lead to their demise 
unless
the reward for doing so is higher than the penalties of being caught.
> 
> (I believe a 20 MB child porn video MPEG sent into the Eternity network
> would leave "footprints" an analyst or watcher could track. I am willing to
> be show the error of my ways, but only with some calculations of diffusion
> entropy, for example.)

> 
> - In short, I want to see some simple descriptions of WHAT IS GOING ON.

I agree.
> 
> It has always been very easy for us to describe how networks of remailers
> work--so simple that at the very first Cypherpunks meeting in '92 we played
> the "crypto anarchy game" with envelope-based remailers, message pools,
> digital cash, escrow, etc. (Running this simulation took several hours, but
> taught us a lot.)


> 
> I'd like to know how Eternity DDS _works_. Then we can start mounting
> attacks on it: spoofing attacks, denial of service attacks, and attacks
> assuming various levels of observability into the network linking the nodes.

That's the primary reason for having both a design document and a demo.  People
can read about how it should work, and attack it at that level, as well as look
at it in operation.
> 
> Until then, I think it's a waste of time and money to be coding a detailed
> implementation of a protocol.

True.  I'm not coding a detailed implementation of a protocol, I'm doing a 
bunch
of minor experiments to see what technical means are feasible, as well as
trying to create something which lets people see how it works.
> 
> (And it may _still_ be a waste of money, even after the protocol is beat
> upon thoroughly. There is no clear market for such a service, and not even
> for remailers. And maybe not even for PGP, in terms of paying customers
> sufficient to pay the bills. Not to criticize PGP, just noting the obvious,
> the same obvious situation that seems to be the case with digital cash.
> Great idea, but where are the customers?)

That's why I'm trying to design the service with security *and* commercial 
usability
in mind.  I believe there are plenty of commercial uses for something with the
right combination.  If something like Eternity DDS exists which is 
indistinguishable to
the user from a web server, and from those adding files from a system superior 
to a web
server (such as a database), yet provides the level of security which I hope 
to provide,
I think there will be a commercial market.

So, I guess in order of priority:
1) list of goals and assumptions for a commercially-viable eternity service,
with cypherpunks-level security, made available for discussion
2) technical design document to meet these goals circulated among
some subset of the community for initial sanity checking
3) functional demo prepared which can demonstrate the feasibility of the system
4) release of 2) and 3) to cypherpunks, eternity, etc. for commentary
5) repeat 2, 3, 4 as necessary
6) production implementation

I've been working on 1, 2, and 3 in parallel but with roughly correct 
distribution
of effort.
> 
> Thanks,
> 
> 
> The Feds have shown their hand: they want a ban on domestic cryptography
> ---------:---------:---------:---------:---------:---------:---------:----
> Timothy C. May              | Crypto Anarchy: encryption, digital money,
> ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
> W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
> Higher Power: 2^2,976,221   | black markets, collapse of governments.
> "National borders aren't even speed bumps on the information superhighway."
> 
> 
> 

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



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

iQEVAwUBNLmuyqwefxtEUY69AQE/iwf6As+DXq0Q+XfaIfvfYX0VKJFhvvBigLWB
6ShAOEIzA2jOSGmzmdVWYfHw2Lan5wRcj0VyCMCJo+YYGfxf62z3clPut2Qm2ABv
j7xzD6oGVwpf0ESzo7ZlsBL57dyhQiX8EjJQD5RQJBPS5/+wvjw0GsmKb3Tw6042
3/T4aVol2x339XtIG+rck7XV6H6kFZeKE8dbfopH9C/7b26d9fbI8JDxFaaqi+Q/
ccPXL+dB3QRHls8rR4BqPwPQ+Z//Ui4j4V2dhHgWyfIHxcnYReh0vPlN8os3rIHw
2dFra1YLXZ50NVEV6GGPnOzwBqn+zqPVQaXBnyrWAClCCRz0JMITBw==
=TE1C
-----END PGP SIGNATURE-----