1997-08-06 - Re: Eternity Uncensorable?

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: mark@unicorn.com
Message Hash: 5b4ed414d1aca0dda269b65f98c8f0ed759276d5cc6ff7f89bb83fc8f1ac6eea
Message ID: <199708061632.RAA03261@server.test.net>
Reply To: <Pine.LNX.3.91.970806145040.16936A-100000@cowboy.dev.madge.com>
UTC Datetime: 1997-08-06 17:42:01 UTC
Raw Date: Thu, 7 Aug 1997 01:42:01 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 7 Aug 1997 01:42:01 +0800
To: mark@unicorn.com
Subject: Re: Eternity Uncensorable?
In-Reply-To: <Pine.LNX.3.91.970806145040.16936A-100000@cowboy.dev.madge.com>
Message-ID: <199708061632.RAA03261@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain





Mark Grant <mark@unicorn.com> writes:
> On Wed, 6 Aug 1997, Adam Back wrote:
> > To do it properly, you'll need a local eternity server if you want to
> > good security of encrypted documents. 
> 
> I'd assume that in the end this is what most people would do; get a Usenet
> feed and run a server locally so that noone knows which URLs you're
> accessing. 

Indeed.  

Similar perhaps to web based remailer interfaces, you can turn on SSL,
but you're still trusting the server, relying on no hackers being able
to crack it, and relying on your estimate of the authenticity of it's
certificate

If there got to be a _lot_ of eternity documents this might get
impractical.  You wouldn't have the disk space for them all.

The distributed USENET cacheing setup could use cope with a big
archive because the content could also be distributed, and forwarded
on request.  So the complexities of doing something clever to allow
digital mixes to obscure your reading habits might come in again.

Incidentally, I think you could use the same methods to obscure
reading the virtual eternity web as you would use to obscure reading
the real web.  Eg. crowds, www.anonymizer.com.  http://*.eternity/
just happens to be likely to end up hosting a load of "hot" stuff
which you might not want to be caught reading in some countries.

> > Turn of logs, and introduce forward secrecy into mixmaster.  
> 
> That's not what I meant; I'm assuming that the mixmaster chain is
> pretty secure. The problem is that when the government find 'nuclear
> terrorist money-laundering kiddie drug porn' on the Eternity server
> they can trace it back to the original Usenet message and then go
> after the remailer operator who posted it. 

They might have a go at that yes.

> Making the remailers disposable or setting them up in free countries
> would work, but I'd prefer a technical solution.

That _is_ the technical solution!  (Disposable remailers).

Here's a repost of something I posted to remailer-ops on this topic at
around the time a few remailer operators felt the heat.  Nothing new
proposed, but this kind of argument was being hashed out here on
cypherpunks years ago, and we still don't have any disposable
remailers.  As close as we've got that I know is perhaps some
psuedo-anonymous remailer operators running off of cyberpass (Lance
offers anon shell accounts for ecash).

Adam

remailer-ops repost:
======================================================================
From: Adam Back <aba@dcs.ex.ac.uk>
To: mail2news@anon.lcs.mit.edu
Cc: remailer-operators@anon.lcs.mit.edu
Subject: disposable camouflaged tents (was Re: Balls remailer under attack.)
In-reply-to: <199706291539.RAA15722@basement.replay.com> (nobody@REPLAY.COM)
Date: Sun, 29 Jun 1997 23:45:40 +0100


Anonymous writes:
> I'm not sure that's a wise precedent to set.  Once you put the
> self-appointed censors and netcops in the driver's seat, who's to say
> where they might take us?

Agreed.

> [description of censors tatics]
>
> Maybe it's time that the censors were told to keep their noses out
> of our tents, for, like a camel, once you let it put its nose under
> the side of your tent, you soon have the entire camel taking over
> your tent!  Maybe it's time to bop a few intruding noses!

The solution is to have disposable tents, lots of.

What about AOL disks?  We need shorter lived, disposable remailers as
exit remailers...  Let them take the heat, while the real remailers
walk.  Lets see a series of "exitman" remailers.  Exitman remailers
are walking targets left to fend for themselves as long as they may.

I propose that an exit remailer is replaceable, that is another
remailer can instantly step into it's place and take traffic.  The way
to do this is to have a special automated reporting mechanism for
exitman remailers.  An easy way to do it is to have the exitman
remailers send mail to a given mailing list.  Other remailers which
wish to use exitman remailers just subscribe to the chosen mailing
list.  We just need a remailer command indicating the creation of a
new exitman remailer.  I guess the exitman remailer just sends one
message per day, or whatever, and if it stops, you write it off.

Is there a military term for something sent in to get shot to bits,
just to distract attention from other movement?  A decoy?


Also, what about camouflaging the disposable tent, so the camal can't
find it to poke it's nose in?  How about SMTP mail forgeries.
Wouldn't addresses of remailer42@dev.null fool a lot of these censorous
people?

I wonder if system admins in general would be very interested in
tracking down SMTP forgeries for censors?  If it was obvious what the
censorous shill was up to, or the large ISP sysadmin was just plain
overloaded with work he may just shrug his shoulders and say sorry,
can't be traced, get over it.

Adam
-- 
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

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`






Thread