Does Cracking Encryption Involve Some Precognition? 22
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?"
Re:Fundamentals of encryption (Score:1)
Which gives us an interesting (practical) weakness in the question-asker's proposal. It is no good obfuscating your file format if it is then going to be wrapped in a standardised compression format by the (pre-processor to) the encryption algorithm.
A good related reference... (Score:1)
*/5 * * * * if [-f $HOME/message-to-send.txt]; (gpg -$OPTIONS < $HOME/message-to-send.txt | mail -s "message" someone@host.net); else (dd if=/dev/urandom bs=1024 count=1 | gpg -$OPTIONS | mail -s "message" someone@host.net); fi
(please pardon if this won't actually run... I'm on a windows box and don't have my man pages handy - but you get the general idea...) Just make sure your message is exactly 1k, set up the appropriate procmail on the other end and... probably nothing. Chances are no one will care, and if they care enough, they'll just put a keyboard sniffer on your machine, find out your password, log in as you, and read your mail anyway. Always remember, you can't win, but sometimes it's fun to try and think of interesting ways to try.
Without precognition (Score:1)
Re:not to mention (Score:1)
Of course, crypto analysis assumes that the encryption scheme is public or will be figured out.
Cipher (Score:1)
Long day....
-Pat
Security through nostalgia (Score:1)
Even assuming the NSA can make sense of a giant pile of mid-80s shareware disks that they might confiscate from you, all the decoding software runs at a comparative snail's pace, making it impractical to try a large number of combinations. (Or do crypto agencies have VIC-20 and Timex Sinclair emulators running on Crays?)
Re:Dear Slashdot, (Score:1)
--
It's lossy. (Score:1)
The approach would therefore be centered on breaking your encryption technique. If I had access to an encoder and decoder, even without knowing how it works, I would know that I should be looking for images. In that case I would compare the encoded file with the decoded image and ignore the original text. Determining that it was rot-128 would be a fairly simple matter.
Re:Same as a machine (Score:2)
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.
If you have a block of encrypted data (Score:2)
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.
Decoding? (Score:2)
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.
Re:Fundamentals of encryption (Score:2)
I am assuming that the decryption attempt also uncompresses the file.
--
You're right (Score:2)
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.
Re: JPEG Specs (Score:2)
A good place to start for this question would be the Usenet JPEG FAQ [faqs.org]; the question is answered here [faqs.org].
Cryptanalysis (Score:2)
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 [cluefactory.org.uk] in the stream of numbers produced. So hope is not lost with modern cyphers.
not to mention (Score:2)
This is the reason why Public-Key is so popular.
Precognition is my secret (Score:3)
By the way, if you're thinking of trying this, you should be aware that I patented it in 2079.
Recognizing Plaintext (Score:3)
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 (Score:3)
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.
--
Same as a machine (Score:3)
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? (Score:4)
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 (Score:4)
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 [cypherus.com]), the content is compressed when encrypted.
-Andrew