5

Hear me out ... On TV shows like Criminal Minds they make it out to appear that any encrypted files can be easily decrypted, even without a key. The character, Garcia, just simply "pushes some buttons" and the file becomes decrypted almost instantly, even without any key, etc. I know that the show is not a good example of REAL WORLD events, but unless they're making a mockery of encryption I can't see why they'd make viewers think it's so easy just because they're F.B.I., as if that makes them magically capable of anything without knowledge.

But here's my point ... An encrypted file is bits; just bits that are garbage unless made back (decrypted) into what they originally were. Isn't it possible, in theory, to work through each byte and try to figure out what it originally was without a key, brute-force, etc.? Why not?

I mean there might be some possible way to determine what the original data may have once been by analyzing data directly yourself using some mathematical, logical, or other pattern first-hand, maybe? Doesn't there have to be some kind of strategy or pattern that can enable one to reverse the data manually?

sleepma
  • 67
  • 1
  • 1
  • 3
  • 2
    Brute-Force works for everything. But at the current state of technology a brute-force attack would consume more energy than the sun could provide within the time that would be required to do a brute-force. For other attacks "using some mathematical, logical" patterns: google for `cryptoanalysis`, `padding-oracle`. But these still consume a lot of time and are not feasible if the encrypting party did a good job. – marstato Jul 18 '14 at 20:38
  • 1
    Actually, brute force *does not* work with a one-time pad because every possible decryption is equally likely. – Bob Brown Mar 27 '16 at 02:15

7 Answers7

24

- Show me the file contents.
- I cannot, chief ! It's encrypted !
- Dammit ! He wins this time.

An so ends the show, 5 minutes after the start.

TV shows don't show the "real world", and that's not to make a mockery; that's because shows aim at pleasing the audience, by providing them the sensations and feelings that they crave for. If it implies depicting events which are distorted, or even physically infeasible, then so be it. After all, Star Wars explosions make noise in the vacuum of space, and Godzilla is an ill-tampered radioactive lizard who breathes fire and insults a giant moth in Japanese while trampling Tokyo.

If encryption is done properly, then it cannot be broken upfront. But nobody said that police forces must act only within the formal mathematical rules of cryptography. In fact, they will first break your door at 06:00 AM and seize your computers and look for traces of the unencrypted data (e.g. parts of deleted files). After all, an encrypted file is useful only if was not encrypted at some point, and will be decrypted at some other point. Whenever a file exists somewhere in unencrypted format, it is prone to leak.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
8

Who knows? (Hint: nobody, unless you're religious.) But generally, no.

The only proven safe "encryption" is a one-time pad but that's very impractical... I'm going to save you the long, technical story.

You have probably heard of some real world encryption algorithms: RSA, AES, RC4, etc. The thing is that we do not know whether any of these are secure, we only know that they've been around for a long time and not yet broken despite many, many attempts. Well, cross out RC4 in the list of safe ones: cryptanalysts' relationship status with RC4 is "it's complicated".

Let's take AES. It translates bits of data into other data. You put "CAT" in, give it key "4ZD" and "YYR" comes out. You give it "YYR", provide key "4ZD" and "CAT" comes out. Of course there is more to it than that, but that's the idea.

If AES would be completely secure, you would need to try all possible keys (in this case AAA through ZZZ and 000 through 999) in order to find that "4ZD" is the correct encryption key. For AES, there are attacks known by which you can find a small bit, for example you can tell that one of the key characters is a digit but you don't know which digit or in which position. Still many possibilities to try.

But this is the best we've been able to do in the 16 years that AES exists. It seems unlikely that it will ever be fully broken. There are security features in AES against things that went wrong in older encryption algorithms:

  • It is, so far as we know, secure against known plaintext attacks. This means that given "CAT" and "YYR", you cannot learn that the key is "4ZD". Why is this useful? Well consider websites: many webpages contain English words. If you intercept https data and run it against an English dictionary, one of the keys that you get would be the correct one for the rest of the webpage. But as I said, this is not possible with AES.

  • AES is, so far as we know, also secure against chosen plaintext attacks. If you are allowed to choose what is going to be encrypted and are then able to see the encryption, you can still not determine the encryption key, thereby still being unable to decrypt the rest of the data.

  • When using similar but not identical passwords, such as P@ssw0rd! and P@ssw0rd1, the encryption result is completely and unpredictably different. Or given similar but not identical texts, it would also be completely different.

So things like guessing the password character for character are not possible. You'd need to get the whole password correct at once. The average number of attempts this takes is (2^password_security_in_bits)/2. Take it from me that with AES-128, this is impossibly long. (Of course 4ZD is not a realistic password.)

There are many more of these known attacks, which our modern encryption algorithms try to protect against of course. The only way to break mainstream encryption is to circumvent it (as far as we know). It might be that the police in your fiction series previously installed a keylogger to record the password from the suspect. It might be that they have a camera recording where the suspect enters his password. Or he might have used a weak password that was crackable in seconds.

Other than that, it's pretty much nonsense.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • Good simplification without losing much significant detail. – Basic Aug 17 '14 at 21:43
  • @FabioTurati Oops, you're right! That should be `/2` instead of `sqrt()`. Maybe I confused it with Grover's algorithm, or maybe I was just mistaken. I've edited the post, thanks! – Luc Oct 05 '18 at 22:29
2

No, not with the current hardware if a good encryption method was used and the key (password) was long enough.

Unless there is a flaw in the algorithm and that you know it, your only option is to brute force it which might takes hundred of years.

If there was really a way to break any encrypted text manually in a short time I would be very worried and I would never ever trust the web for anything like online banking.

Gudradain
  • 6,921
  • 2
  • 26
  • 43
1

Depending on the type of encryption used, yes it is possible for a brute force attack to be successful. The Wikipedia article I reference below states, " A cipher with a key length of N bits can be broken in a worst-case time proportional to 2N and an average time of half that."

There are however certain encryption types that are unbreakable through the use of a brute force attack.

e-sushi
  • 1,296
  • 2
  • 14
  • 41
Ryan M
  • 119
  • 5
0

I know that the explanation seems to ask about the possibility of cracking encryption keys, but to take the question literally, no in general a file cannot reveal useful information without applying the intended decryption key because a key is the mapping from the encrypted information that you have to the intended information. The odds of another mapping that is not the key revealing the encrypted information are dismal, besides in trivial cases where different keys or combinations of keys can produce the same output with the same input, or when this behavior was intended:

AES encryption with multiple keys

Of course this seems obvious, but it is not theoretically impossible that you could decipher information with a different key than what was intended, however unlikely.

Say 'cab' is encrypted to '213' the procedure is obvious, convert to numbers and reverse, but this is not a one-to-one mapping because the steps to decipher can be reversed, yielding a different key, not necessarily the one intended, and still give the correct, unencrypted result. I think it's safe to say that today's encryption methods make something as improbable as this impossible, particularly in one-to-one mappings.

As an aside, the best way to break non-trivial encryption without having possession of the key is at the source. Using encryption we trust that the information was encrypted successfully by the program we're using. By gaining control of the user program it is possible to either prevent the information from being encrypted (not an answer to the question), or manipulate the program to encrypt, then unencrypt the information on the user computer prior to sending, which would allow decryption without actually possessing the key, or having any knowledge of the key; although the key would be under attacker control so maybe that doesn't qualify either. Then it would have to be encrypted again so the recipient receives the proper message. Not practical, but it's the only way I could see to decipher it without having the key.

Pang
  • 185
  • 6
flerb
  • 450
  • 2
  • 14
0

Assuming we use absolutely no information about what the message may look like, it's fundamentally impossible to "just brute force without key" not because you can not find a key that will reveal the secret message, but because you can find keys to reveal every possible message (in reallity, only as many as there are possible keys), and you will not know which of the messages is the secret one.

In any practical case, one would use some additional knowledge in an attack, which makes the attack not "perfectly brute force" in the general sense used above.

Volker Siegel
  • 119
  • 8
  • This is only true for a one time pad, not for other, more practical and commonly used encryption methods. – Michael Borgwardt Jul 19 '14 at 02:18
  • Ok, for other algorithms, the key is shorter than the encrypted message, so trying all keys can not create all messages, only a subset of all messages. When not assuming additional knowledge (like "that looks like a message") that does not change much, I think. – Volker Siegel Jul 19 '14 at 02:25
  • 1
    Let's take a concrete example. Suppose you have a 128-bit key/password/whatever. You know that you have have a 8KB email message, encoded in ascii. There are about 2^24000 possible values for 8Kb, but the key can only decode to 2^128 possible messages. If we assume that all characters in the real message will be between 32 and 126, we now have enough information to brute-force the message (assuming that we have an infinite amount of computing power). The tricky part is usually getting your hands on this infinitely powerful computer. – Patrick M Jul 19 '14 at 19:01
  • Ok, added emphasis on the "no extra information" aspect. Oh, and these computers can be easily build from unobtanium! – Volker Siegel Jul 19 '14 at 19:11
  • @VolkerSiegel Except, I'd say that in most cases, people do have an idea of what they're going to decrypt looks like. The whole point of most encryption is just force people to brute-force the encryption if they want to open it. It's usually a given that if the attacker has the CPU power to try every option, he can usually decrypt the message. Instead of relying on keeping the type of data secret, it's often much easier to just use a form of encryption that takes too long to brute-force. The trick is to pick something that will generally take more than 10^20 years to brute-force. – Patrick M Jul 19 '14 at 23:43
0

Cryptographic algorithms are designed with several goals in mind:

  1. To make the encrypted output (cipher text) perfectly indistinguishable from actual random numbers. That is to say, there are no patterns in the cipher text. Any encryption scheme worth using will do this extremely well.
  2. To use a key and algorithm combination of sufficient length and complexity, respectively, so as to make brute-forcing the key (by trying every possible value until you find the right one) so impractical that it will not even be attempted.
  3. To make the decryption process (and in most cases the encryption process) efficient enough that it is practical in terms of time and power consumption.

It is important to remember that these are often competing factors. All encryption algorithms can be ranked on how well they achieve each of those goals, and you'll find that no one algorithm is best at achieving all of them. So, some sacrifice the quality of the randomness, the complexity of the algorithm, or the length of the key, in the name of efficiency. This sometimes introduces vulnerabilities that make brute-forcing the key easier (often by reducing the possible values, or key space).

I think the most interesting real-world methods for breaking crypto systems come from a type of cryptanalysis known as a side channel attack. These take advantage of the fact that a cryptographic algorithm is not just a theoretic method of transforming numbers, but must exist as a system that uses hardware to transfer data, handle the key, and perform the series of computations necessary to arrive at an encrypted or decrypted result. Cryptographic systems leak information in a number of interesting ways you might not imagine. Heat, light, sound, and EM (electromagnetic) radiation--among other channels--can all be used to "listen" to and record the workings of the crypto system. By statistically analyzing the recordings, the key space can often be reduced enough to make an informed brute-force attack practical. The first time I learned how to perform a side channel attack using the EM energy radiating through the top of a microchip, I really felt like I was in a spy movie using some seriously futuristic technology. This kind of attack is by no means a silver bullet, but it's the closest thing--publicly documented--to what you see in movies and television.

Eric
  • 101
  • 2