Re: Hidden encrypted messages

> 
>    What about encoding a message by chnging spacing between the words?
> It is surely not the most compact method, but one might be able to transmit
> a pretty long message hidden in the text of "Alice in Wonderland" that
> would still be neatly formatted and *word-to-word* indistinguishable from
> the original.
>    
>  Alex.
> 
  
  Of course, if someone knew what they were looking for, it "would be trivial"
to set up some sort of filter to find this type of message (in this case, one
with a great number of spaces).  This assumes unnoticability due to lack of
knowledge, which is the current thought process being applied to computer
security.  It's a very falible one, as many companies have found.  If you
assume whatever kind of filter you may be dealing with will be a program
(and not a person) looking for a certain frequency of special characters, or
just a range in which >90% of your characters fall (like do you use many more
alphanumerics than *&&*^%$#'s?) then you could just have every fifth letter 
in your _Alice_ transmission be a character of your encrypted message..
  On the other hand, in dealing with that kind of program, I'm sure you could
write some program that would represent non-alphanumerics with a recognizable
code of alphanumerics which wouldn't be normally generated by the encryptor
(and failing that, just convert the entire piece to hex or something..).

Hmm, in writing this it seems to me that hiding a encrypted file in a way that
would evade anything drempt up to distiguish it from text is a lot more 
difficult than just calling it something else:  "Umm, yeah Mr. NSA, that was
a sound file of the pgp sound format!  ..right."  (or that noise suggestion too)

ghoast@gnu.ai.mit.edu   (Devin Jones)

Devin Jones responds to Alex:

> Hmm, in writing this it seems to me that hiding a encrypted file in a way that
> would evade anything drempt up to distiguish it from text is a lot more 
> difficult than just calling it something else:  "Umm, yeah Mr. NSA, that was
> a sound file of the pgp sound format!  ..right."

Alex's (good) idea about using creative spacing to hide an encrypted message
is similar to that what I'd originally proposed (and of course it has to
be hiding an *encrypted* message!).  I've gotten a number of responses
of the form "Why not just claim that an encrypted message is data?",
but my original point was Plausible Deniability.  That is, I was
postulating an environment in which Big Brother has outlawed cryptography.
Now, confronted with a confiscated message, the sender has to defend
himself from the Inquisition.  Can't just claim it's a sound file;
the Inquisitor will want it played.  The question I'm trying to answer
is how to produce on demand a causal explanation of data (which actually
contains an encrypted message) that satisfies an investigator and
doesn't reveal the encrypted message.  Some simple scheme like, "Uh,
it's the result of my new random number generation algorithm" isn't
likely to be *satisfying* and is certain to produce the response,
"OK, let's see the algorithm."

derek
don't bother running sophisticated analyses of the above message (oops,
I suppose that's a suspicious thing to say)

Derek Zahn says:
> ....................I've gotten a number of responses
> of the form "Why not just claim that an encrypted message is data?",
> but my original point was Plausible Deniability.  That is, I was
> postulating an environment in which Big Brother has outlawed cryptography.
> Now, confronted with a confiscated message, the sender has to defend
> himself from the Inquisition.  Can't just claim it's a sound file;
> the Inquisitor will want it played.  The question I'm trying to answer
> is how to produce on demand a causal explanation of data (which actually
> contains an encrypted message) that satisfies an investigator and
> doesn't reveal the encrypted message.  Some simple scheme like, "Uh,
> it's the result of my new random number generation algorithm" isn't
> likely to be *satisfying* and is certain to produce the response,
> "OK, let's see the algorithm."

Yes, a very valid point.  But it seems to me, that Random Data
claim is the best, with the highest chances to keep one out of
trouble (if anything can :-).

The algorithm? Oh, sorry, but it's a HARDWARE random data generator!
And if it's truly good random gen, there are no patterns to track...
One can use it to create huge one-time pads, BTW...   "Salt" some of
the encrypted (or plaintext :-) messages with those...

The only thing to be concerned of - the cipher [to be claimed a
random data] shouldn't be crackable, and SHOULDN'T have any
patterns! Or they could present an evidence, that the
data isn't a product of your random gen...
--
Regards,
Uri         uri@watson.ibm.com      scifi!angmar!uri 	N2RIU
-----------
<Disclamer>


From cypherpunks-request  Thu Mar 11 12:44:24 1993

> Alex's (good) idea about using creative spacing to hide an encrypted message
> is similar to that what I'd originally proposed (and of course it has to
> be hiding an *encrypted* message!).  I've gotten a number of responses
> of the form "Why not just claim that an encrypted message is data?",
> but my original point was Plausible Deniability.  That is, I was
> postulating an environment in which Big Brother has outlawed cryptography.
> Now, confronted with a confiscated message, the sender has to defend
> himself from the Inquisition.  Can't just claim it's a sound file;
> the Inquisitor will want it played.  The question I'm trying to answer

So I say, "Damn! CRC Error!  Must be a bad disk.  Well, no point in keeping
THIS sitting around."

> is how to produce on demand a causal explanation of data (which actually
> contains an encrypted message) that satisfies an investigator and
> doesn't reveal the encrypted message.  Some simple scheme like, "Uh,

I understand what you want.  Wish I understood how to do it. ;^)

> it's the result of my new random number generation algorithm" isn't
> likely to be *satisfying* and is certain to produce the response,
> "OK, let's see the algorithm."
+----------------------+----------------------------------------------------+
| J. Michael Diehl ;-) |  I thought I was wrong once.  But, I was mistaken. |
|                      +----------------------------------------------------+
| mdiehl@triton.unm.edu| "I'm just looking for the opportunity to be        |
| Thunder@forum        |            Politically Incorrect!                  |
| (505) 299-2282       |                        <me>                        |
+----------------------+----------------------------------------------------+

> So I say, "Damn! CRC Error!  Must be a bad disk.  Well, no point in keeping
 > THIS sitting around."

Yeah, but remember, in the world we're heading to, presumption
of innocence is worth even less, than President's word!
Then it will be *your* responsibility to satisfy the
Inquisitor, or he might not let you out from his
building, where you were invited to explain
yourself and your messages. (:-) (:-(

 > > is how to produce on demand a causal explanation of data (which actually
 > > contains an encrypted message) that satisfies an investigator and
 > > doesn't reveal the encrypted message.  Some simple scheme like, "Uh,
 > > it's the result of my new random number generation algorithm" isn't
 > > likely to be *satisfying* and is certain to produce the response,
 > > "OK, let's see the algorithm."

And the response to this will be: "Sure, here it is, this
nice hardware implementation. You may have it, if you
wish!" (:-)  It's fool-proof, but  still the Big
Brother might dislike your desire to play with
those bad random generators, and decide,
that you better be kept in KZ-camp...

Probably creating a  GIF/TIFF/whatever  file yourself,
with normal consumer-grade equipment (noise-prone :-)
and substituting it's LSB (or whatever certainly lies
BELOW the noise floor) with bits of the message, does
sound like the best choice today.

Advantages:
	1) Doesn't look suspicious, no more, than
	   "traditional" sending photos of your
	   house, family, yourself...

	2) Has enough of bandwidth to communicate
	   reasonably large personal messages
	   (though a binary og PGP might
	   not fit into a "normal"
	   GIF file :-).

	3) Requires only widely available consumer
	   appliances (Camcoder, digitizer, .....).

	4) The image doesn't have to be known to your
	   correspondent in advance (a big one!).

Disadvantages:
	1) Somebody has to do it, to write code, to
	   buy a Camcoder (:-).

	2) May lead to outlawing of ALL the image and
	   sound transmission  via  electronic media,
	   if Big Brother gets really annoyed (:-).

	   [Don't laugh, you! Look at the latest
	    Scanner Bill! :-]

Regards,
Uri.
------------
<Disclaimer>