1995-01-12 - Re: How do I know if its encrypted?

Header Data

From: eric@remailer.net (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 6112c994572ac8d8c8b544c9709e368860870a10f3b901d7dbd171cab4800c6d
Message ID: <199501121612.IAA00824@largo.remailer.net>
Reply To: <199501120646.WAA28573@ix2.ix.netcom.com>
UTC Datetime: 1995-01-12 16:14:14 UTC
Raw Date: Thu, 12 Jan 95 08:14:14 PST

Raw message

From: eric@remailer.net (Eric Hughes)
Date: Thu, 12 Jan 95 08:14:14 PST
To: cypherpunks@toad.com
Subject: Re: How do I know if its encrypted?
In-Reply-To: <199501120646.WAA28573@ix2.ix.netcom.com>
Message-ID: <199501121612.IAA00824@largo.remailer.net>
MIME-Version: 1.0
Content-Type: text/plain


   From: daleh@ix.netcom.com (Dale Harrison (AEGIS))

   It's an artificial example, but one that points out that merely doing a 
   frequency analysis on the datastream isn't enough to guantee the correct 
   answer.

You don't always need the correct answer.  You just need the correct
answer most of the time.  You're trying to create a presumption about
behavior.  Ensuring that you can't read almost all of the traffic is a
pretty good way to assure people that you don't try to make sense of
any of it.

The fundamental purpose here is social communication about intent.

   Reliable remailer software will have to worry about false postives 
   as well as false negatives; especially if it's a fee-for-service operation.

I just don't agree with this.  If you feel it needful to install an
entropy filter, expect that its failures will simply accrue to the
general unrealiability measurement for that remailer.

And there's no reason you couldn't publish the algorithm so that a
user couldn't check the entropy for themselves in advance.

   Of course the implicit assumption in that statement is that encrypted 
   traffic hasn't been outlawed or regulated, or that the sender doesn't want 
   to 'appear' to be sending encrypted traffic.

I don't design for the paranoid.

Eric






Thread