From: Black Unicorn <unicorn@access.digex.net>
Date: Wed, 11 Jan 95 08:56:21 PST
To: wcs@anchor.ho.att.com
Subject: Re: Data Haven problems
In-Reply-To: <9501090448.AA14477@anchor.ho.att.com>
Message-ID: <Pine.SUN.3.91.950111114558.11283A-100000@access3.digex.net>
MIME-Version: 1.0
Content-Type: text/plain


On Sun, 8 Jan 1995 wcs@anchor.ho.att.com wrote:

> Date: Sun, 8 Jan 95 23:48:36 EST
> From: wcs@anchor.ho.att.com
> To: dfloyd@io.com
> Cc: cypherpunks@toad.com
> Subject: Re: Data Haven problems
> 
> dfloyd asks for ideas about preventing spamming in data havens,
> for the code that he's working on.  It's a hard job.
> A related problem is how to prevent your data haven from becoming
> the porno-ftp site of the week, and either being swamped with
> traffic or raided by the Post Office Reactionary Neighborhood Police.
> 

[Problems of payment schemes and lack of anonymous payment infastructure 
deleted]

> Some operators may find it useful to limit the amount of data
> that can be stored or retrieved by a specific user or site, 
> though this is less useful with anonymous and pseudonymous remailers
> around, since "a specific user" becomes vaguer.
> 
> Filtering by filename and type can also be useful - if you don't allow
> files named *.gif and *.jpg, users may be less likely to
> spam you with pornography.  Namespace control in general is an issue -
> do users get to choose filenames, or list directories, or do they
> have to know the names of files to retrieve. 
> Another issue is whether files can only be retrieved by the sender -
> probably a local policy issue.  

To some degree this requires the evaluation of the "authority attention" 
level the data haven has achieved.  If the real sensitive data is more 
extreme than a porn deposit, (I assume we are talking 'legal' and not 
kiddie porn BTW) then the spam involved will serve to properly mask, to 
some degree, stego'd files within the porn.  Part of a data haven, it 
seems to me, will be security by obscurity.  Just on the basic level that 
a haven with all encrypted files will be somewhat secure by obscure, in 
that the authority most likely to be interested in the data probably will 
not be attentive.  A repository holding some legitimate spam, be it porn 
or gifs or whatever, is unlikely to attract the level of SERIOUS 
attention that the sensitive data it contains may warrant.

To sum:  Spam's usefullness is a function of current authority attention, 
likely authority attention and authority attention the sensitive data 
warrants.

 
> Some sites may only accept encrypted files, which reduces the spam 
> potential considerably, as well as reducing your exposure to the
> porn police, though it's difficult to do anything about files that are
> encrypted with a public key whose private key has been posted to the net,
> or fake crypto headers in an otherwise unencrypted file,
> unless you put in lots more code to check the insides of files and
> watch the net for such postings, which is unrealistic.  There's also
> the problem that PGP and especially RIPEM files are non-stealthy,
> and users may not want to leave even keyids in their files.

A better policy might be to encrypt all files that are not encypted, 
perhaps through some key assignment system.  The spam thus adds to the 
total traffic analysis problem, and the security of the spam is not 
material.  i.e. better encrypted spam than plaintext spam.

> 		Bill
> 

-uni- (Dark)
0

073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!