Re: How do I know if its encrypted?
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.]
On Thu, 12 Jan 1995, Jonathan Rochkind wrote:
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.
Graphics files are already compressed, so they pass the entropy test, but they start with a distinctive header. The best way to stop graphics would be a volume limit per apparent source and per apparent destination. To program that is a bit like hard work. --------------------------------------------------------------------- We have the right to defend ourselves and our property, because of the kind of animals that we http://nw.com/jamesd/ are. True law derives from this right, not from James A. Donald the arbitrary power of the omnipotent state. jamesd@netcom.com
Jonathan Rochkind wrote:
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
As I said in a recent message, there is no general way to "prove" that a file is encrypted, only to have pretty good confidence that it is. (This is at the core of algorithmic information theory, a la Kolmogorov and Chaitin, goes to the heart of what is meant by "randomness," and is linked as well to the halting problem and other such stuff.) I had a need to actually do what Jonathan is talking about: make a file look like it was encrypted but actually have a simple text message in it. My application was an experiment to bait the line for some thought policemen who decided that they would decide which pictures were approprate and which were not. So, I created a plausible-looking PGP-like file and posted it to the new group "alt.binaries.pictures.erotica.children" and announce that an "interesting" picture existed there. The squeals of the net.cops were impressive to behold! Demands to Netcom that I be expelled from the Net, that the "Child Welfare Agents" would soon be breaking down my doors, etc. But, given the climate of our time (this was in July 1993) and given the potential failure of the "It's not a _real_ file" defense, I protected myself in any easy way, but running an English message down the diagonal, saying something like "This is not a real encrypted file," etc. Even a lawyer would have to admit that no real encrypted file could have English emerging randomly. Entropy, and all that. So, this was an ostensibly encrypted file which contained unencrypted text. It would very likely have passed any tests for "randomness" and hence would have been passed by any "encrypted only" filters. (The English text was a tiny fraction of the entire file, so the deviation from near-maximal entropy would likely go undetected. Fluctuations would be larger, depending on file size.) Nobody spotted the message. After several days, I "let the truth be told," which of course enraged others. I though this digression might be amusing to some. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo@toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay
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. Each of these data formats has it's own regex recognizers available. Just apply them. The point, though, is to enforce the presumption that the remailer operator does not, in fact, look at the traffic in order to understand the content. You don't need a completely airtight algorithm in order to do this. Eric
participants (4)
-
eric＠remailer.net -
James A. Donald -
jrochkin＠cs.oberlin.edu -
tcmay＠netcom.com