21

If I encrypt, say, a .pdf file, then does knowing that it's a .pdf make it easier to decrypt?

i.e. could the file's well-known structure act as a predictable part of the encrypted bytes?

38

For practical purposes, no.

Against good crypto, using modern ciphers and making no major mistakes such as a padding oracle or ECB mode or other weakness, it doesn't really help. It can theoretically act as a test for whether you brute-forced the key correctly - does the decrypted file contain the right magic number and data format? Good, you got the right key - but actually brute-forcing the key should be impossible for any modern widely-used cipher (even the weakest form of AES, with 128-bit keys, would take centuries for even a nation-state to brute-force, even assuming Moore's Law continues on course; using only modern hardware it would take many orders of magnitude longer).


Of course, people do make mistakes in crypto, and some ciphers that were once thought strong are now known to be vulnerable.

If you know that the file was encrypted in a particular way, and you know of a weakness in that method, then you can attempt to exploit that weakness. This might be made easier by knowing the file type, as some files are generated by software which nominally supports encryption but implements it very weakly, and knowing that the file is of that type will suggest you might be able to try such attacks (though it won't help you if the file was encrypted using some other tool that implements the crypto correctly).

The ECB (Electronic Code Book) block cipher mode of operation mentioned above encrypts every block (typically 16 bytes for modern ciphers; historically often only 8 bytes) using the same algorithm (for a given key), no matter where it is in the message. This means that if you break the message (or any number of messages, if they were all known to be encrypted using the same key) up into blocks and find two identical blocks, you'll know they're the same plain text. If you find such duplicates and know at least some of the plain text of one of them, because you know at least part of the data of the file (due to knowing its format, or for other reasons), you now know the plaintext for the same part of the other block. This can also be useful when you know the data format in general even if you don't know any specific bytes in it, especially if it's low-entropy data such as a simple image file; see the link above for a striking example of taking a bitmap image, encrypting it using ECB, and the ciphertext (if rendered as a bitmap) still largely revealing the content of the image.

There are other attacks that are less likely to be relevant here, but might be relevant in other situations. For example, if you can get the same data encrypted many times using the RC4 (sometimes called ARC4 or ARCFOUR) stream cipher, you can exploit biases in the "key stream" (the bits generated by the pseudorandom function that a stream cipher is) to slowly decrypt the data; this is why RC4 is no longer trusted for use in SSL/TLS (although for a given blob of data encrypted only once, this attack isn't viable). Padding oracle attacks allow you to decrypt a message (typically one encrypted using a block cipher such as AES in the CBC mode of operation) in linear time, provided there's an "oracle" that knows the decryption key and will, on command, decrypt any message and tell you if the padding (padding is necessary for block ciphers) is correct. Such an oracle is usually not available for a file at rest, but a padding oracle is the reason the that CBC mode can no longer be used in SSL, and led to the deprecation of the entire SSL protocol (TLS includes protections against padding oracle attacks).

Knowing the structure and some basic data about the file can also enable bit-flipping attacks (where you don't decrypt the data, but do change it in a predictable way that could further your causes against whoever legitimately uses the file). This is getting pretty far afield of your question, but it's sometimes relevant when you're attacking an encrypted file of which you have minimal but non-zero knowledge.

| improve this answer | |
5

Yes in the sense that it is easier to detect when your brute force has tried the correct key. If you know it is a text file written in English, you can check the letter frequencies. If it is a format that has header information, you can check if the header makes sense. If it is an executable file you can check if the distribution of codes is close to reasonable. If you don't know what file type you are looking for, how do you know when you have found the right decryption?

| improve this answer | |
  • This must be a necessary part of brute forcing a file regardless. – Ian Warburton Apr 20 at 2:53
  • 3
    @IanWarburton: compare with the possibility the file contains binary data. How do you recognize when you have the right key? – Ross Millikan Apr 20 at 4:47
  • I feel like the answers saying it helps because it makes brute forcing easier are kind of coming at the issue sideways - knowing the (probable) file type and/or being able to easily detect a plaintext is commonplace enough that a reasonable encryption scheme would not be expected to rely on an unpredictable file type / ambiguous plaintext as an aspect of the security of the scheme. – thomasrutter Apr 20 at 5:39
  • Taken to an extreme, where the file is optimally compressed such that all possible decryptions of it seem equally likely, then there's information-theoretic security equal to the entropy of the key. For example, if the key-size is 512-bits, then there'd be 2^512 possible plaintexts that'd seem equally probable, even to an unbound attacker with infinite computational power. That said, it'd probably be worth explaining that, even without this property, the attacker isn't spared from having to do a brute-force search. – Nat Apr 21 at 4:22
  • 1
    It wasn't for fun. It was published in an age when many people did not have access to computers. If you needed some random digits, you threw some dice to get a page number, maybe again for the line, and started reading. – Ross Millikan Apr 29 at 5:22
2

Potentially - yes. Such information reduces entropy and thus requires less attempts to brute-force it. But I say potentially, because it holds only if the attacker can really improve his brute-forcing algorithm for a particular file type. And this is far not trivial. One of the reasons is that at the beginning of encryption data are usually transformed by applying some random data, e.g. by applying xor.

| improve this answer | |
  • So it's more a theoretical rather than practical risk? – Ian Warburton Apr 19 at 4:01
  • 2
    @IanWarburton: You didn't tell us what encryption you mean. If you mean some reliable algorithm like AES-256 GCM, and if you use some standard library, not self made implementation, then you should not worry, there is no risk of brute-forcing because of knowledge of file type. – mentallurg Apr 19 at 13:13
  • 2
    @IanWarburton extremely theoretical, as it only makes bruteforcing slightly easier because you'll know you're on the right track if the first few bytes of the potential decryption are (in this instance) a PDF header. This is known as a crib and modern crypto design assumes an attacker will have some, so quite some effort has gone into making them as little use as possible. – Shadur Apr 19 at 14:26
  • @mentallurg "self-made implementation" - gosh no! – Ian Warburton Apr 20 at 2:14
  • 1
    @IanWarburton: You haven't said anything about that :) Just add this constraint to your question. – mentallurg Apr 20 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.