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
The point is that the system can *always* be spammed. You *don't* charge
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 01:04 PM 1/18/98 -0600, Jim Choate wrote: the 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`
participants (3)
-
Jonathan Wienke
-
Kent Crispin
-
Ryan Lackey