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

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

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