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>
participants (4)
-
derek＠cs.wisc.edu -
ghoast＠gnu.ai.mit.edu -
J. Michael Diehl -
uri＠watson.ibm.com