up vote 1 down vote favorite
share [g+] share [fb]

I know there are a lot of encryption programs available, that I would guess use different methods for encryption, and thus have different types of output files (.fve .tc .cha .dmg (bitlocker, truecrypt, challenger, ect.)), but if someone didn't know what the file was and just looked at the data, what would it look like? Does it just look like random bits, or can you still pick out a pattern? If it does look random, how is it if I moved the encrypted file to another computer, the other computer can tell it's a file, and is able to decrypt it (how would it even know where to start or stop, if it all looked random)? Also, how is the structure affected by encrypting files twice, using the same method, or a different one? Thanks for any help, and if you know any books or site about encryption for complete idiots, I'd appreciate it!

link|improve this question
1  
books: for beginners "The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography" by simon singh, for programmers "Practical Cryptography" by bruce schneier and niels ferguson – akira May 30 '10 at 14:08
feedback

3 Answers

up vote 3 down vote accepted

A well encrypted file (or data) looks like random data, there is no discernibly pattern.

When you give an encrypted file to a decryption program (DCP) it tries to decrypt a small portion of the file. This part contains meta information for the DCP.

If the DCP succeeds in reading that decrypted portion of the file you have the correct DCP and password, then the DCP continues to decrypt the entire file. If the DCP fails you either have the wrong password OR are using the wrong decryption method. If this happens there is no way to know witch went wrong.

Note.
This does not apply to some encryption applications most notably those that are archive applications. Two examples ate zip and rar witch have an outer container that will allow you to detect what application was used to create them

link|improve this answer
Quick question then, if you split the encrypted file so that the header with the metadata for the DCP was on a separate piece, would the DCP be unable to unencrypt the rest of the file? Would the only other option be to brute-force decrypt the rest of the data with all types of keys and methods of encryption and see if any result in a pattern? It seems like this would be more secure, so you would have to memorize both password and encryption type, or just keep the header with you as a key. – Brett Johnson Dec 24 '10 at 2:39
It would increase security, but only because you have part of the file separated from the rest. In a well designed encryption algorithm you can't decrypt the total if a piece is missing. And even when you have all the pieces you still have to know the encryption method beforehand or you'll have to try them all. – Nifle Dec 24 '10 at 7:55
feedback
up vote 2 down vote

perfectly encrypted data looks like perfect random noise.

whenever encrypted data was broken (and not by some 007 obtaining the passphrase from the wife of the villain), the encrypted data did not look that much random to clever mathematicians. as long as it is just perfect random noise, the only attack left (except 007 and the girls) is brute force, which tries to try every possible key and checks, if the decrypted contains something with a pattern (words, pixels)

regarding your subquestions:

  • a computer does not know, how to handle a file by itself. normally you help it (or better, you help the OS) to append a suffix and then the OS looks up a table of suffices and if one fits then it just launches the associated application. that application itself "does not know" if the stuff thats in the file is "ok for the user". you can merge a .gif image and a .zip file and you could open this file with either an image viewer or a zip program (see here)

  • the original structure of the data is not affected by the encryption, even if you encrypt it 3 times. otherwise you can not restore the original data, the structure of the original data IS the data.

link|improve this answer
Ok! I did read about that .zip / .gif merger thing. One question though, so from Nifle's answer, I know that when opening the merged file as a .zip, it looks for the metadata at one end of the file, and opening as a .gif it looks for metadata at the other end, which is why they can be merged. But are there any limitations or standards on where you can put the metadata? Could I invent a 3rd type that has metadata in the middle, and make a 3-way merged file, openable by .gif, .zip, and the new .whatever in the middle? – Brett Johnson May 30 '10 at 15:48
@Fros Shadow: exactly. you can come up with whatever fancy file layout you want. how to interpret the bytes in a file is completely up to the application. – akira May 30 '10 at 16:57
+1 for 007 and the girls - the best (and only) method for breaking modern strong encryption. :) – Ilari Kajaste Jul 22 '10 at 9:30
feedback
up vote 0 down vote

Encrypted files should just look like random data, but sometimes they have headers that can be used to identify what kind of file they are.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard