1995-01-13 - Re: Data Havens..A consumer perspective

Header Data

From: Nesta Stubbs <root@nesta.pr.mcs.net>
To: Cypherpunks <cypherpunks@toad.com>
Message Hash: 32b4dc20d2d271322ea4c113b586a7c28c5eeb35fa02ffb94c788af5c4624079
Message ID: <Pine.3.89.9501130117.C28998-0100000@nesta.pr.mcs.net>
Reply To: <ab3b21760302100490ca@[132.162.201.201]>
UTC Datetime: 1995-01-13 08:13:56 UTC
Raw Date: Fri, 13 Jan 95 00:13:56 PST

Raw message

From: Nesta Stubbs <root@nesta.pr.mcs.net>
Date: Fri, 13 Jan 95 00:13:56 PST
To: Cypherpunks <cypherpunks@toad.com>
Subject: Re: Data Havens..A consumer perspective
In-Reply-To: <ab3b21760302100490ca@[132.162.201.201]>
Message-ID: <Pine.3.89.9501130117.C28998-0100000@nesta.pr.mcs.net>
MIME-Version: 1.0
Content-Type: text/plain


On Thu, 12 Jan 1995, Jonathan Rochkind wrote:

> At 4:30 AM 01/12/95, Nesta Stubbs wrote:
> You shouldn't ever give the operator the info in plaintext. Encrypt it,
> public or otherwise, and distribute the key to your Band of Merry Men.
> Then it doesn't matter even it's sitting on a public access Unix system, no
> one can read it anyhow.  The main point of this kind of data haven seems to
> be providing you a remote location to store your data, in an anonymous way,
> so even if it does end up being found out, you can't be linked to it.  I
> wouldn't trust the operator to do anything particular with the data other
> then keep it safe enough so I can retrieve it later, and I'd take the
> neccesary precautions to account for that lack of trust. The only reason
> I'd trust him to even keep it safe for me, is because of reputation market.
> If he routinely loses people's data, word is going to get around. On the
> other hand, if he routinely shows people's data to the FBI, no one is even
> going to know about it. I don't trust him not to routinely show the data to
> the FBI, or store it in public.  Use encryption.
>
first note that in carol ann's post she previously said it doesn't matter 
to her how the data is transported, and thus it could be in paintext, I 
made.  and also that she said that the operator should be able to specify 
how it was transmitted.

once again we're running with different definitions of data haven.  I see 
the ata haven as more than just aplace to safely store data if it's 
encrypted, I see it capabel of alot of other things, like acting as a 
central point to  BlackNet type operation, with the proper structure set 
up to carry out the transactions with safety, or relative safety.  also, 
as a anonymous drop box type of place, I can then send my encrypted data 
to the data haven, and let them hold it until some anonymous client or 
eployer and I complete an agreed upon contract and both give word to the 
data haven to complete it's aprt of the contract, wether it is allowing 
the other person to now access that encrypted information, or doing a 
monetary transaction with net-cash or whatever.  Also, as a data base of 
illegl information, like old credit records and such.

> Of course there are different purposes for data havens, which would require
> more trust of the operator.  But I'm not sure how well those are ever going
> to work, because I'd much rather trust my encryption then trust the
> operator.
>
agreed. there are also other operations besides data storage that can be 
protected by your own crypto, and only use the data haven as a mid-point.

argh, I'm sorry fo the poor typing in this letter, and the other one i 
sent to Eric ont his subject, it's really late and I am dogged, just got 
done 9 hours of work.  BUt this topic is so interesting for me I couldnt 
resist.  Tommorow if I get a chance I will atttempt to outline what *I* 
think of when I am saying data haven, maybe it will help us be more 
productive, not that we arent doing that now...





Thread