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?"

Comments

Precognition is my secret

[Anonymous Coward]

I crack encryption with a time machine. Whenever I fail to crack encryption, I send a message to myself back in time saying not to try that particular method. When I get the message, I try any other method. When that fails, I append that method to my original method and send that back in time. I continue doing this, the list growing with more and more failed attempts. Now when I start the task, I have a long list of things not to try. When I try a method not on the list that turns out to be successful, I send a message back to myself with the successful method, and I'm done. All that information about successful and failed attempts comes from a vanishing loop of virtual time, and because of this policy whenever I need to crack something I get a message telling me exactly what to do. If I'm really feeling ambitious, I can brute-force 128-bit keys this way.

By the way, if you're thinking of trying this, you should be aware that I patented it in 2079.

Recognizing Plaintext

[Tim Dierks]

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.)

Fundamentals of encryption

[yamla]

The fundamental assumption of strong encryption is that the attacker knows everything except the specific secret key. The algorithm should be secure regardless. This is true for things like one time pads, Triple-DES, etc. etc. provided the secret key is long enough.

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.

--

Re:Fundamentals of encryption

[torinth]

The fundamental assumption of strong encryption is that the attacker knows everything except the specific secret key. The algorithm should be secure regardless. This is true for things like one time pads, Triple-DES, etc. etc. provided the secret key is long enough.

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. All Good points. Except:

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.

For the exact reason you mentioned, strongly-encrypted files do use compression. It provides a higher entropy before the data goes in. Compressed data is effectively random data, and there's nothin wrong with encrypting random data. The only thing I can imagine you mean is that strongly-encrypted files, in the purist sense, are uncompressed. But certainly in Practical applications (hehe. shameless plug: Cypherus), the content is compressed when encrypted.

-Andrew

Same as a machine

[stubob]

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.

Where are your finite variables?

[dmorin]

Ok, your file exists in a finite system where you have 8bit bytes:

1. Look for magic numbers and header info to see if the file is of a known format.
2. If not, execute rot X on it.
3. Repeat while X It would be a quick test. Does that imply that the person knew you'd rot'd it first? Nope -- just that if you've got a finite variable over which you can test (mod the size of your byte) then at one point or another you should test it.

   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?)