Slashdot Mirror
Does Cracking Encryption Involve Some Precognition?
jcapell asks: "Let's say I sent an encrypted message using any method that could normally be 'cracked' relatively quickly using brute-force or complex algorithms. Wouldn't any decoding require some minimal knowledge of the format of the contents? What if I (for example) printed out my message, took a photo of the text with a digital camera, and then ran the resulting .jpg file through rot-128? How would an unintended recipient know where to start decoding the message?"
Errr... I think you mean asymmetric encryption. Symmetric algorithms use the same key for encryption and decryption, so there is no difference between sender and recipient.
--Matthew
And have no idea what method of encryption was used and what the "plain text" should look like you may have a very tough time. It may even be imposible as when you do decrypt it you may not even know depending on the data.
Many things like the number stations on short wave will probably never be decrypted for that very reason, ofcourse in that case there may not be any data at all it could just be random numbers most of the time.
Erlang Developer and podcaster
Although I'm not familiar with the format of a .jpg file, there probably is a certain pattern near the beginning due to the definition of the compression patterns. (Yes, I'm ignoring the actual header which announces the file type -- that's too easy) Someone who does this for a living would recognize that type of pattern hiding behind simple encryptions of this type. There probably are some sort of record markers which separate each chunk of the picture, and the pattern of those markers would also reveal clues to the encryption. JPEG also uses compression, and the codes used to indicate reuse of compressed values would also provide patterns (ie, the green in a field of grass may provide a cluster of patterns).
I once had to deal with an encrypted mail system which was being used by thieves. The programmer of the mail system had used a standard library routine which sometimes left a space at the end of a line of text. It was easy to see the patterns of those spaces, and from the way the spaces were encrypted the encryption algorithm and its key were easy to find. The program was available, so the encryption algorithm could have been extracted from the program, but it wasn't necessary to do so -- although the program was also studied later to confirm that it was understood properly.
I am assuming that the decryption attempt also uncompresses the file.
--
Oceania has always been at war with Eastasia.
Random noise has several testable statistical properties. All n-bit values appear about equally often, if this n-bit value is x the probability that the next n-bit value is x is 2^^-n, and so forth. The longer the message, the more exactly these probabilities can be tested.
Almost all possible messages pass the tests for random noise. Almost all sets of data that people care about do not pass the tests for random noise. So, the cryptanalyst applies these tests and looks more carefully at any decryption that doesn't pass the tests for random noise.
Knowing what encryption method was used or what message is being sent helps immensely, though.
A good place to start for this question would be the Usenet JPEG FAQ; the question is answered here.
It is more difficult to develop a sense for this when considering non-text input. It is more difficult to see how it could work when using modern cyphers. But the principles are the same.
Any particular type of message will have some standard formatting information, some patterns that the cryptanalyst can look for. The modern, popular, RC4 stream cipher does have a perceptable bias in the stream of numbers produced. So hope is not lost with modern cyphers.
If you want someone else to decrypt this message you need some way of communicating to them on what to do to decrypt it. How do you tell them? Another encrypted message? Recurse ad infinitum.
This is the reason why Public-Key is so popular.
Check out Althea for a stable IMAP email client for X. Now with SSL!
By the way, if you're thinking of trying this, you should be aware that I patented it in 2079.
The problem you are describing is the problem of how to recognize plaintext; when we stumble across the correct decryption key, how can we recognize it?
The first part of the answer is that, for security analysis purposes, we generally assume that the attacker knows what system we're using, starting with what the encryption algorithm is, but including the type & format of the messages. If the attacker knows you're sending a rot128 jpeg image, she can just reverse the process to recover the message (or test a key for correctness).
If you believe that an attacker will not know these details of the system, you will add to security, but watch out: the secret of the system can be pretty easily divulged, and even if the attacker doesn't know the secret of the system, it's pretty hard to estimate how hard it will be to guess it. (For example, every rot-128'd JPEG file will begin with the bytes 0x7F 0x68; sooner or later, someone is going to notice and figure it out.)
Certainly obfuscating the decryption adds some security, but this is only security through obscurity. It adds less additional security than keeping the encryption algorithm secret. It adds far less than choosing a decent key-size. Heck, it adds less additional security than adding a single bit to the secret key, probably.
The basic problem is that you can never trust security-through-obscurity. If I am protecting trade documents, for example, I may be able to keep my secret key secret but I'm not likely to be able to protect the details of the algorithm (here I'm counting the algorithm itself and the additional obfuscation at the end) because ex-employees or partner companies or some such will necessarily need details of the algorithm.
On top of that, unless your obfuscation is truly secure, you can tell when you've decrypted most files. Most files compress. By definition, strongly-encrypted files do not. So you could see how much entropy is in your test decryption. 8 bits per byte? Then you probably haven't successfully decrypted yet.
--
Oceania has always been at war with Eastasia.
How does your computer know that a jpeg is a jpeg? Somewhere in the hex is a tag that says what it is (the infamous CAFEBABE, for example). Some people just seem more able to pick up common elements. I'd imagine that a real code breaker would brute force a bunch of methods (rotX, XOR, etc) and see if anything looks familiar. Kind of like the code breaking scene in (IIRC)'Clear and Present Danger' where guy starts using 'Birthday, wife's birthday, etc.' and surprises Harrison Ford.
What you are proposing is basically a one-time pad, though. The receiver can't decode it either without knowing how you encoded it. Just like you couldn't decode it without knowing how you encoded it. That's what makes symmetric encryption algorithms so useful. You allow someone the ability to decode your message without giving them the ability to encrypt a message as you.
Planning to be moderated ± 1: Bad Pun.
Even in an astronomically huge system, that's a good place to start. When you have a crypto puzzle in a magazine to solve, what's the first letter you look for? A or I, because you know that those are your 1-letter words (assuming that you know that your puzzle consists of english words in the first place). Then E because it's most common, and so on. Wherever you can get a hook, you don't lose anything by trying it out.
Think of it as a variation on "your security is only as strong as the weakest link." In this case, what could give you away is the 8bit nature of your data. Not to mention potential patterns in the nature of the image (don't many image file formats have large sections of constant data if you were to dump them out?)
www.HearMySoulSpeak.com