From: Ryan Lackey <rdl@mit.edu>
To: Jim Choate <ravage@ssz.com>
Message Hash: 7294fb3339618fc23725e594ce462b54d6c7e087caaecd9626ff9431dc31d496
Message ID: <tw790sdllr5.fsf@the-great-machine.mit.edu>
Reply To: N/A
UTC Datetime: 1998-01-18 17:48:30 UTC
Raw Date: Mon, 19 Jan 1998 01:48:30 +0800
From: Ryan Lackey <rdl@mit.edu>
Date: Mon, 19 Jan 1998 01:48:30 +0800
To: Jim Choate <ravage@ssz.com>
Subject: Re: (eternity) Eternity as a secure filesystem/backup medium (fwd)
Message-ID: <tw790sdllr5.fsf@the-great-machine.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
(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/
Return to January 1998
Return to “Ryan Lackey <rdl@mit.edu>”