At 12:40 AM 01/12/95, Dale Harrison (AEGIS wrote:
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.
The context this was being discussed in, was trying to make _plaintext_ look like _ciphertext_. The operator of a data haven or remailer might hypothetically want to ensure that all text he dealt with was encrypted. So your method wouldn't do anything in that area. Unless you can think of a way to embed plaintext in ciphertext in such a way that it looks like ciphertext, and my guess is that any method that did that well would be sufficiently obscure as to be analagous to encryption for our purposes. Really bad encryption, with very little point, but still hidden text. Which is the real point, the operator doesn't want to deal with any text that isn't "hidden" in some way. Of course, we're not just dealing with text. So the scheme has got to be changed a bit so as to be able to detect unencrypted GIFs, and mu-law files, and as yet to be determined unknown files. I don't know enough about what's being talked about to know if this entropy detecting stuff will generalize to non text files. Cause we want to catch unencrypted GIFs too. [And doesn't compression alone do similar things to the entropy as encryption does, anyhow? If someone compresses their file with a good compression algorithm, as I understand it the non-randomness left will be pretty low. But it won't meet the needs we're discussing, I don't think.]