Re: How do I know if its encrypted?

You wrote: 

>
>   My question is how do I know it is encrypted?  
>
>Calculate an entropy measure of some sort.  Entropy is a measure of
>disributional skew.  Maximum entropy means minimum skew.
>
>For human-readable text of any sort, the monogram entropy, i.e. the
>entropy of individual characters, will _always_ be detectably less
>than maximal.  Encrypted text will always be near maximal.  The two
>are easy to distinguish.  ASCII-armored encrypted text will always be
>right at 6 bits per byte.
>
>For speed of implementation, you don't need even to look at much text.
>You can get a statistically significant measure quite quickly from the
>first couple of kilobytes.  
>
>And since you're only really worried about detecting non-randomness,
>you don't even need to calculate the exact entropy but rather an
>approximation of it.  This approximation can be done with entirely
>fixed point arithmetic, if you're a bit clever about it.
>
>A practical system would cut out a notch at 6/8 for ASCII armor, which
>would make approximation techniques a bit tricky.  More practical is
>just to detect ASCII armor with a regular expression recognizer and
>de-armor it before the entropy check.
>
>Eric
>
>
Won't work!  You can always embed an encrypted message in what 'looks' 
like plaintext.  A trivial example: Encrypt a message with a caesar 
cypher, then build a story where the first char of each word maps to 
each subsequent char from the encrypted text.  At the cost of expanding 
the size of the message by a factor of 5 to 10 you've hidden the 
encrypted message in what looks like a letter to your mother (or a news 
story in the NY Times, etc.)  This is old technique.

Dale H.

On Wed, 11 Jan 1995, Dale Harrison wrote:
> >
> >A practical system would cut out a notch at 6/8 for ASCII armor, which
> >would make approximation techniques a bit tricky.  More practical is
> >just to detect ASCII armor with a regular expression recognizer and
> >de-armor it before the entropy check.
> >
> >Eric
> >
> >
> Won't work!  You can always embed an encrypted message in what 'looks' 
> like plaintext.  A trivial example: Encrypt a message with a caesar 
> cypher, then build a story where the first char of each word maps to 
> each subsequent char from the encrypted text.  At the cost of expanding 
> the size of the message by a factor of 5 to 10 you've hidden the 
> encrypted message in what looks like a letter to your mother (or a news 
> story in the NY Times, etc.)  This is old technique.
> 
> Dale H.

But Dale, hat doesn't matter much.  the user is then going otu of his way 
tpo get rejected.  The data haven would be knwon to it's users to require 
encrypted text, and a user who did the scheme you outline above would 
only be succeding in getting himself rejected.  I mean it's nothe 
operators fault he decided to be snazzy and put iit in plaintext when it 
was known to be required to be encrypted, as in knowingly encrypted.

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

   Won't work!  You can always embed an encrypted message in what 'looks' 
   like plaintext.

So people can write special software that gets their message rejected
by an entropy filter.  This is a disadvantage?  It looks like an
irrelevancy to me.

Seems to me that a quite reasonable condition of use of a remailer is
that what is passed isn't human readable.

Eric