Help me understand, what stops all encrypted files having cribs

I'd been pondering recently,

We all know that in historic cryptography if you know someting of the plain text and roughly where in the message it occurs you can use this to work out the key, the decrypt the entire message from it. Alan Turing (and Tommy Flowers)'s cracking of engima was based on this idea, they knew engima would never encrypt a latetr as itself, and knew what words might be in the message so compared the word against the message and checked if a ueful key could be found whenever they found a place where the word didn't match any letters of the encrypted text.

When one encrypts, lets stick to symmetrric crypto considerations for now, a file, then one can guarantee that the file has a header unique to its file type. The likes of gpg will, when making encrypted copies of a file even keep the extension. secretFile.jpg becomes secretFile.jpg.gpg, any attacker would immediately know what header info would be at the start of the the encrypted file. Why would they not be able to use this as a crib to fully reverse engineer the whole file and find out what was inside?

Also, one assumes in the case where an attacker sees both the plain "text" file and the encrypted file that typical cryptography methods must do something to ensure that even with both to hand the attacker cannot reverse engineer the key. Aferall, the key may sometimes be a mroe important secret than the file itself if it is used in multiple places.

How do common (symmetric) encryption methods:
a ) defend against the crib of file type headers
and
b ) prevent reverse engineering of the encryption password if an attacker has both the unencrypted file and the encrypted one

Or are both a and b actually huge vulnerabilities in all cryptography? One would assume not as surely cryptographers will have worked out how to prevent both cases.

Thanks

Edited by rp88, 08 June 2023 - 09:52 AM.

Hi,

 

(a) It's common for crypto algorithms to pad the data they're encrypting with random garbage bytes. 

Similarly, after the encrypted data is decrypted, the random garbage bytes are implicitly discarded.

This means you could make (e.g. 20 identical copies of a file) and encrypt each one with the same key data, and end up with 20 completely different encrypted files (that when decrypted result in the same original file data)  The random data is largely what enables the various permutations and complicates the searching.

 

( This depends on the specific algorithm you're using.  For example, with AES there is Electronic Code Book (ECB) mode which is garbage if you're encrypting more than one block of data.  Other modes CBC, GCM, XTS, ... have been implemented to address identified security/performance issues.

 

I'm of the mindset that everything will be eventually be decryptable...so if you have data that is encrypted (e.g. ransomware, forgotten password, etc.) and that data will still be important to you at some point in the future, back it up along with everything else you have related to the encryption (app that encrypted it, if known, ransom notes (if applicable).