1998-01-18 - Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)

Header Data

From: Jim Choate <ravage@ssz.com>
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Message Hash: c1299f9dcc70b4b0b685657f9e1a31bf4d79521e88c4623798b6dde9c0738a49
Message ID: <199801181904.NAA17705@einstein.ssz.com>
Reply To: N/A
UTC Datetime: 1998-01-18 18:36:50 UTC
Raw Date: Mon, 19 Jan 1998 02:36:50 +0800

Raw message

From: Jim Choate <ravage@ssz.com>
Date: Mon, 19 Jan 1998 02:36:50 +0800
To: cypherpunks@ssz.com (Cypherpunks Distributed Remailer)
Subject: Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)
Message-ID: <199801181904.NAA17705@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text

Forwarded message:

> Subject: Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)
> From: Ryan Lackey <rdl@mit.edu>
> Date: 18 Jan 1998 12:45:02 -0500

> True.  But in an Eternity model without copyright, someone could be one of
> the first customers to download the data, then upload it again under a
> different name.

So in your model there isn't any form of check on the data for redundency?

> The only thing the original uploader would have as
> an advantage would be indexing information, potentially -- it's easier
> for me to download ms word by going to the eternity equivalent of
> http://www.microsoft.com/ than to go to 
> http://www3.pop3-167.adhoc.warez.location.ai/edf3/filez1.zip.

Not if it's:

http://ww.microsoft.com/software/commercial/wordprocessing/msword/x.y/ \

This is a specious point. The fact is that from the users perspective the
index would automagicaly provide the actual resting place for the server
to find it, even if it were on a different server. The whole point is to
make the software do the druggery. The length of the pathname or URL is
irrelevant at that point.

> There's no real way to put the genie back into the bottle unless you can
> send people with guns to beat people up who store your data as a third party.

The point being that if we take the average user of a data haven model they
don't have the resources (money, technical skill, bandwidth, etc.) to set up
a data haven of their own. Further, the storing of the data by other parties
isn't the issue, it isn't the data havens data. This is one of the primary
reasons that really important data should be expensive to get initialy. It
goes back to what I was saying in a previous post about Grace Hoppers
worth-v-time model.

> Data disappears from Eternity once no one cares enough about it to pay to
> have it stored.

What this over-looks is the potential for that data to become relevant to
some currently unknown situation in the future. While I agree that the data
should not necessarily be in a fast medium storage after a certain time
period it should not simply be thrown away. If nothing else at some point it
will have historical (inexpensive, it's still money) relevance.

> Providing eternity service costs money.

Life costs money, that is one of the reasons that you don't want to throw
stuff away that may bring in income down the road.

> Anything which lets users circumvent
> this opens up the potential for denial of service through consumption of
> resources attacks.

There simply isn't a way around that except to out bandwidth the attacker.

> Even if billing is fundamental, you still have the
> potential for the NSA to spend $100m to buy all the eternity space available
> at any point.
>  This is why you also need market mechanisms
> -- if the NSA
> is willing to pay a premium for eternity service just to keep it out of
> the hands of the populace, then running eternity servers is a great 
> investment, so capacity will increase until the NSA can no longer afford
> to buy all of it.

I like it when you write my own rebuttal for me...:)
The bottem line is that the market mechanism *is* the willingness of some
party to buy that space. Nothing more, nothing less. Further, Mallet ain't
stupid or he'd have starved a long time ago.

> A difficult part of designing a working Eternity service is to keep people
> from "stealing service", in terms of consumption of resources, during
> set up, indexing, etc.  Basically, you need to make sure that to the 
> greatest extent possible, anything which is a potentially scarce resource
> is sold, not given away.

The point is that *nothing* is given away for free, though you might want to
let people *give* you resources for free. Which is the point I was making.

> You then are vulnerable to someone spamming the system, unless you give
> the server operator some way of knowing if this encrypted data is likely
> to be valuable.

The point is that the system can *always* be spammed. You *don't* charge the
source of data a million dollars to put it on your server. It's gotta be
source cheap or else it isn't worth their time to bother with it. If you
*really* want to promote such servers what you need is a model that allows
submitters free access *and* a share in the subscribers fees. Then everyone

If the source has something they know is worth god awful sums of money they
aren't going to submit it to the data haven anyway, they'll set their own
haven up and reap the benefits directly. There is an economic issue here
that is at parity with the technical issues.

> You can have arbitrarily complex payment models, since the enforcement
> agents can exist (must exist?) as eternity objects in their own right.

Not really, at some point the complexity works against itself - you should
study a little chaos theory. The final point is to make the system (ie the
logical linking of black box operations that themselves may be quite
technical or complex) dirt simple.

> No, the most feasible attacks for a resourced attacker are custom ASICs
> optimized for key testing, as were recently described.  Distributed
> workstation cracking is a parlor trick if you have a billion dollar budget
> for key cracking.

Tell that to the NSA and their Cray-acres. The point is that even if you
have customer ASIC's or FPGA's or whatever these are still computers and you
can't seriously be suggesting that the resources to create customer hardware
for specific goals is any less complicated or more inexpensive than using
general purpose hardware when looked at from a global scale. If that model
were so generaly applicable then we should move all our processing jobs to
ASIC's and reap the benefits. There is also the issue that even if you use
customer chips to develop customer key cracking hardware (which I agree is
being done as we speak) there is still the inescapable fact that you will
need lots(!) of them. So the result is that whether they are custom or
general purpose devices the sheer quantity becomes a hinderance.

> The NSA has general purpose HPC resources for purposes like signal processing,
> AI, etc., not for brute forcing people's keys routinely (although perhaps for 
> a weak and nonstandard cipher, it would make sense to use general purpose
> machines).  Even a corporation would be better off using FPGAs or ASICs for
> key cracking once you get past 56 bits.

That would depend on the economics of startup and what kind of footprint
that would leave in the industry. This is one of the reasons that the NSA
builds their own chips.

> I assume the attacker is evil and rational.

My, my. Moral stipulations are probably no more relevant than psychological
classifications. The issue is one of emotion. Mallet wants it because it
benefits Mallet and hinders Mallets enemies. This is an emotional reason
and most definitely outside the bounds of simple rational/irrational action
classification. When I was speaking of psychology earlier in my submissions
I was not the least bit implying any comment on rationality, goodness, or
other relative classifications. I was refering to greed, pride, honor,
self-respect, etc. as motivations. The interactions of those in individuals
and organizations doesn't depend on classifications.

>  I also assume that the
> entire legal system has been subverted, and that extralegal operations of
> any size too small to make the new york times front page are possible.  And,
> any entity which deals with the government (just about any) can be subverted.

Any government can be subverted as well, happens on a regular basis. The
legal system may not need to be subverted for the simple reason that more
than one legal system may be involved. The front page example you are so
fond of is a instance that would take, my guess, probably in the
neighborhood of $10k to have a full page for a single day. To make the
participants investment in that sum worth it, what is their pay off in your
system? Just having their name in the paper probably isn't worth it. The
wide public advertisment, and hence notoriety is probably not a big plus
either. Especialy considering that it would guarantee the participant a nice
bug-for-life experience.

> Thinking that the major internet gateways between providers are bugged by
> the NSA isn't really too unreasonable if you accept those assumptions.

Whether the providers themselves are bugged are not is really irrelevant,
its the backbone infrastructure providers who are providing the access points.
You tap the satellite transfer point, for example, not the 300 organizations
sending data down it. You tap the telephone switch in each neighborhood, not
the individual lines on their subscriber end trunks.

   |                                                                    |
   |       The most powerful passion in life is not love or hate,       |
   |       but the desire to edit somebody elses words.                 |
   |                                                                    |
   |                                  Sign in Ed Barsis' office         |
   |                                                                    | 
   |            _____                             The Armadillo Group   |
   |         ,::////;::-.                           Austin, Tx. USA     |
   |        /:'///// ``::>/|/                     http://www.ssz.com/   |
   |      .',  ||||    `/( e\                                           |
   |  -====~~mm-'`-```-mm --'-                         Jim Choate       |
   |                                                 ravage@ssz.com     |
   |                                                  512-451-7087      |