Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)

(Jim Choate) writes:

> Ryan Lackey writes: 
> > Once your DBC escrow
> > "account" runs out, the data is worthless
> 
> That's a jump of logic. The data may infact be quite popular even though you
> don't offer it anymore (might even do this in order to increase its worth, 
> say some sort of insider trader newsletter). It's probably not in the best
> interest of the data haven model to speculate on exactly why a particular
> source decides to quit sourcing.

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.  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.

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.

Data disappears from Eternity once no one cares enough about it to pay to
have it stored.  That could mean someone doesn't pay in advance for the data,
or no one is willing to invest disk space in the hope that it will in
the future be downloaded.

Providing eternity service costs money.  Anything which lets users circumvent
this opens up the potential for denial of service through consumption of
resources attacks.  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.

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.

> 
> > remain in Eternity forever if no one cares enough about it to pay to
> > have it stored.
> 
> Then again, if it was really important I might intentionaly want to attack
> the ability to provide long-term income. A better model might be to charge
> for the access and let the actual submission be no charge. A portion of the
> retrieval charge could then be piped back to the source. Consider the case
> of say nuclear or biological information for a weapon. That sort of data
> would be accessed only infrequently (unless you're giving something this
> expensive to obtain and verify away - a d-h operator error, no.) but should
> be quite expensive to retrieve.

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.

I think both payment models should coexist.  But there's no reason that
the server operators are the only people able to speculate -- it could
be just another random user.

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

> 
> > If the data is still relevant and worth breaking in 50 years, they could
> > just intercept the encrypted email, store it in a government vault for
> > 50 years,
> 
> More realisticaly they would have somebody just add it to a batch job and
> let the spare cycles of the machines crank away at it. Or perhaps set up a
> key challenge and get people all over the world to work on it in their spare
> cycles. Who knows, perhaps the source of the data woudl be intriqued enough
> to provide spare cycles unknowingly.

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.

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.

> 
> > If you do not postulate that level of signals collection capability on the
> 
> It's not just their sig-int capability but their complete processing
> resource capability that must be considered as well as their psychological
> motivation. Granted, all of these are extremely difficult to measure let
> alone verify. Perhaps a little paranoia might be a good thing.

I assume the attacker is evil and rational.  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.

Thinking that the major internet gateways between providers are bugged by
the NSA isn't really too unreasonable if you accept those assumptions.
> 
> 
> 
>     ____________________________________________________________________
>    |                                                                    |
>    |       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      |
>    |____________________________________________________________________|

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

On Sun, Jan 18, 1998 at 12:45:02PM -0500, Ryan Lackey wrote:
[...]
> 
> Data disappears from Eternity once no one cares enough about it to pay to
> have it stored.  That could mean someone doesn't pay in advance for the data,
> or no one is willing to invest disk space in the hope that it will in
> the future be downloaded.
> 
> Providing eternity service costs money.  Anything which lets users circumvent
> this opens up the potential for denial of service through consumption of
> resources attacks.  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.
> 
> 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.

There are alternative ways of paying for the service that do not in
any way depend on ecash, and after thinking about it a bit, they seem
more robust, as well. 

The basic idea is as follows:  The fundamental eternity service is 
free to readers, and is financed entirely by writers.  The writers 
supply the disk space, the network bandwidth, and possibly pay for 
the software to support all this.

In a little more detail: you have say 1 megabyte of data that you
would like to be stored in the Eternity Service.  The overhead of
storage in eternity is a factor of two, and you would like 10 times
redundancy.  So you contact the Eternity Service Software provider, and 
get the software.  You then configure the software to supply 20 
megabytes of your disk space to the system.  This allows you to 
supply 1 meg of your own data.

The 20 megs will of course not store *your* data -- it will store
other eternity data.  The service takes your data and spreads it
across 10 other sites, whose locations are unknown and unknowable to
you.  In return, you are storing eternity data for other users.  If
your disk space becomes unavailable your file disappears from the
service.  (Of course, someone else could pick it up and store it, if
it was valuable information.)

This is a self-financing model.  Every writer to the eternity service
pays for their own bandwidth and disk space.  The eternity service
provider is financed by maintaining the software that all the writers
use -- client/server software will have to run on many different
platforms, some protocols may be better than others, and it might be 
worth buying your eternity software from a high-reputation 
("trustworthy") provider.

Note that this doesn't mean that data suppliers can't be paid for
providing data -- but that is a completely separable problem that can
have many different solutions.

I believe this approach does solve the financing part.  But it does
make the rest a *very* complicated problem -- you have a dynamic,
self-configuring network of data sources and sinks, with all the
configuration data encrypted along with the data.  Ideally, of course,
the data would be migrating constantly. 

Retrieval would probably be very slow -- basically email speeds, or 
worse.  In fact, perhaps the data would be retrieved by having the 
eternity service use the remailer network to send it...

-- 
Kent Crispin				"No reason to get excited",
kent@songbird.com			the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


At 01:04 PM 1/18/98 -0600, Jim Choate wrote:
>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
>wins.
>
>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.

Here is a way for an individual to make money using the eternity service:

1:  Users are charged $/MB/month to store data in the service.

2:  Users are charged $/MB for downloading data from the service.

3:  The source of a data item receives a portion of the download fees
collected for that item as an anonymous payment, or else the money could be
applied toward keeping the data on the service (the option of choice for
the really paranoid among us).


At 12:02 PM 1/18/98 -0800, Kent Crispin wrote:
>In a little more detail: you have say 1 megabyte of data that you
>would like to be stored in the Eternity Service.  The overhead of
>storage in eternity is a factor of two, and you would like 10 times
>redundancy.  So you contact the Eternity Service Software provider, and 
>get the software.  You then configure the software to supply 20 
>megabytes of your disk space to the system.  This allows you to 
>supply 1 meg of your own data.
>
>The 20 megs will of course not store *your* data -- it will store
>other eternity data.  The service takes your data and spreads it
>across 10 other sites, whose locations are unknown and unknowable to
>you.  In return, you are storing eternity data for other users.  If
>your disk space becomes unavailable your file disappears from the
>service.  (Of course, someone else could pick it up and store it, if
>it was valuable information.)

The location of the data should be determined by some sort of random
process, and it should move frequently.  Disallowing one to store one's own
data reduces the number possible locations for the data, and also requires
a mechanism for matching the source of the data to the owner of each node-
both of which are Really Bad Karma.

>This is a self-financing model.  Every writer to the eternity service
>pays for their own bandwidth and disk space.  The eternity service
>provider is financed by maintaining the software that all the writers
>use -- client/server software will have to run on many different
>platforms, some protocols may be better than others, and it might be 
>worth buying your eternity software from a high-reputation 
>("trustworthy") provider.

One could also construct a fee schedule where a higher rate would buy a
higher redundancy level for your data.

>Note that this doesn't mean that data suppliers can't be paid for
>providing data -- but that is a completely separable problem that can
>have many different solutions.
>
>I believe this approach does solve the financing part.  But it does
>make the rest a *very* complicated problem -- you have a dynamic,
>self-configuring network of data sources and sinks, with all the
>configuration data encrypted along with the data.  Ideally, of course,
>the data would be migrating constantly. 
>
>Retrieval would probably be very slow -- basically email speeds, or 
>worse.  In fact, perhaps the data would be retrieved by having the 
>eternity service use the remailer network to send it...

The eternity service should be its own remailer network--one that transfers
data as well as e-mail.  The nodes should have constant encrypted cover
traffic between them.

-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5

iQA/AwUBNMKMicJF0kXqpw3MEQJ/sACfQpkRqLflEPdmr4NpsP/8w7WEmvIAnjvv
LSkxnt7fdHwkCk37vMWf/q1A
=P6/D
-----END PGP SIGNATURE-----


Jonathan Wienke

PGP Key Fingerprints:
7484 2FB7 7588 ACD1  3A8F 778A 7407 2928
3312 6597 8258 9A9E D9FA  4878 C245 D245 EAA7 0DCC

"If ye love wealth greater than liberty, the tranquility of servitude
greater than the animating contest for freedom, go home from us in peace.
We seek not your counsel, nor your arms. Crouch down and lick the hand that
feeds you. May your chains set lightly upon you; and may posterity forget
that ye were our countrymen."
-- Samuel Adams

"Stupidity is the one arena of of human achievement where most people
fulfill their potential."
-- Jonathan Wienke

Never sign a contract that contains the phrase "first-born child."

When the government fears the people there is liberty.
When the people fear the government there is tyranny.
Those who live by the sword get shot by those who don't. 

RSA export-o-matic:
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`