Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!osiris.cso.uiuc.edu!leather
From: leather@osiris.cso.uiuc.edu
Newsgroups: sci.crypt
Subject: Re: how do you tell encrytped data from
Message-ID: <3600002@osiris.cso.uiuc.edu>
Date: 8 Jan 88 19:15:00 GMT
References: <660@bucket.UUCP>
Lines: 44
Nf-ID: #R:bucket.UUCP:660:osiris.cso.uiuc.edu:3600002:000:2545
Nf-From: osiris.cso.uiuc.edu!leather    Jan  8 13:15:00 1988


> /* Written 11:36 pm  Jan  5, 1988 by leonard@bucket.UUCP ...   */
> /* ---------- "how do you tell encrytped data from" ---------- */
> An interesting question has crossed my mind. If someone presents you with
> an allegedly encrypted message, How can you tell if it really is encrypted
> as opposed to being a bunch of random characters?
> 
> [...] 
> 
	Although the _suspicious_ nature of an even distribution of letters
may be a give-away indication of *JUNK* messages for amateur and "semi-pro"
encryption schemes, it cannot be absolute proof.

	I have dabbled some in the crypto-analysis field, myself.  It is not
difficult to think of some methods for creating *SMOOTH* distributin messages:
	1.  massage the message with your existing encryption scheme,
	2.  perform a distribution analysis on the encoded result,
	3.  obtain the complementary distribution analysis - for *SMOOTHNESS*,
	4.  apply a padding of additional characters to the previously
 	    encoded result, yielding the smoothed encrypted message:
		a.  padding could be in the form of "encasing" the previously
		    encoded result (either/both ends of message by line, block,
		    ...),
		b.  or "enbedding" the characters in some simple/complex 
                    pattern.

	The real question is why bother, except to annoy or distract?
If you have a sufficiently effetive cypher to begin with, why add complexity
to its encoding/decoding process?  If you are going to hide a *REAL* message
in a diversionary barrage of *JUNK* messages, you could just as well hide it
in *JUNK* that used ordinary English, French, Russian, Chinese, ... sentence
packages, in which case the _normal_ distribution patterns are going to lead
to equally wrong conclusions.  The point is, there are ever so many ways for
going about this business of encryption that one analysis technique alone is
insufficient to determine what *IS* or *IS_NOT* encrypted data.  Even if one
goes to the trouble of using a less complex technique for encryption of some
message, who is to say that the _message_ was not the *JUNK*.  GIGO (garbage
in, garbage out)?  It may be *JUNK*, but it _was_ encrypted!  But then, ....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  David A. Leatherman                  ~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  (ARPA: leather@osiris.cso.uiuc.edu)  ~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~         leathrmn@uxe.cso.uiuc.edu     ~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~