Various questions about file compression and encryption regarding hacking (zip, rar, 7z)

Question

So I'm curious about a few aspects of compressed files (Zip, rar, 7z, etc), and how they impact hack-ability. There is enough on this subject that I'm not clear about (since this isn't a career of mine, and I don't know too much about coding) that I'd like to ask a few questions all-together. You can skip down to the questions now if you want, but a bit of context can't hurt. I've done some research on encryption and file compression, but what I learned was more technical rather than action-reaction.

What I Know

I know that the method used to hack into a file depends largely on the hacker. I'm only aware of two methods of doing so.

1. -Password generators (Basically a program spits out every combination of password possible, starting from 1 character and increasing).

2. -Forced entry (I have little to no knowledge on this one. I can only assume that the hacker has intimate understanding of the encryption method, like AES for zip, then reverse engineers that to force entry into the encrypted folder without worrying about the password).

The Scenario

Lets assume that all methods of hacking/cracking into this compressed folder are available to our theoretical hacker. Let's assume that the hacker has no previous knowledge of my password, and that there was no spyware or key-loggers on my computer. The hacker has no intimate knowledge of me so he doesn't simply have the ability to guess my password or make an inference.

In the first scenario, if the hacker encounters a single zipped or otherwise compressed folder which is password protected, then a single file inside that folder (lets say the file is a notepad file with my credit card information in it), how might he go about hacking into that, what are his options here?

Then, in scenario number two, he encounters a multi layered folder; 3 password protected zips before reaching the file containing valuable information. Each password is different, so theoretically the password cracker would take 3 times as long. How might he go about his hack now?

And in the final scenario, there are at least 5 different layers, but each level gets more complex. If you were to map out the various paths possible, it would look more like a tree now rather than a straight line down. Also, the person who zipped this thing replaced/removed some of the file name extensions, so instead of the files being called "Folder.zip" they are now called something like "Folder.psd", "Folder.png", or "Folder.bat", something a bit more deceptive. The person who zipped this might have also diversified the file extensions, he sprinkled in a few zips, a few rars, a few 7zs and others. He switched their names too, so "Folder.zip" might be named "Folder.rar" or it might be named "Folder.zip", but the hacker doesn't know on the onset. The person who packed it also added some dummy files, and some "fluff" in the empty folders to make it seem like they contained valuable data instead of just being empty. This thing is labyrinthine, it's menacing, it employs long passwords and many different compression types. It's got misleading file extensions that aren't obvious at first. it's meant to seem predictable at first, but then just becomes more difficult if not impossible.

The Questions

1. -Does using multiple layers of compression slow the hacker down?

2. -Does the length and complexity of a password slow the hacker down?

3. -Does changing the file extension name slow the hacker down? I'm not aware of software out there that identifies the file type, and I'm not sure if by looking at the code, he is able to discern the file type himself (or in what way he would be looking at the code).

4. -If the file is named "Folder.rar" but it's actually a "Folder.7z" file, will this slow down the hacker? Will he continuously attempt to breach the file without having any knowledge of his error?

5. -If a folder has multiple compressions and routes, like the one depicted in scenario 3, does a hacker necessarily have to go down all of those routes? Or does he have a way of circumventing or automatically getting to the desired file? I would assume that if the encryption method like AES is compromised, then the hacker could just jump through each folder without even knowing the password.

(In case you're curious about how these questions could relate to people in general, they pertain to such circumstances as archival, computer sharing, the use of cloud and external storages, and the protecting of valuable/sensitive data)

Answer 1

TL;DR; If the data is valuable, "slow down" will fix nothing.

1. a script can be written to uncompress multi-level compression
2. Brute force is possible. And also the password protection mechanism, using AES-256 is recommended.
3. No. If you use linux, you will know OS will ignore the extension and learn the file header signature. Check this out : list of file signature
4. Check No.3 answer. A script can easily check the file signature and use proper decompress tools.
5. Check No.1 answer

Well, if I want to have some fun, I might plant tons of Zip bomb to "slow down" the attacker if they "hack" into my honeypot server and copy those zip bomb.

Or perhaps, include a zip bomb under every password protected archive and render the automation script useless.

Answer 2

Many of the techniques you suggest are Security Through Obscurity. For example, naming a zip file as a psd will only slow down the attacker slightly. Using multiple different types of encryption and compression adds unnecessary complexity. It is true that complexity can slow down the attacker, but Security Through Obscurity has very limited effect, especially in the context:

Lets assume that all methods of hacking/cracking into this compressed folder are available to our theoretical hacker.

First we should understand that Compression is not going to secure the files. That is the job of Encryption. A Password Protected zip may be encrypted, depending on which program you use.

Robust encryption is sufficient against the most sophisticated attackers, if properly implemented.

Determining whether the program you use is suitable for this purpose is a separate question. I'm focusing on the underlying algorithms a program should use.

Once the sensitive data is combined into a single file (i.e. a zip file), then encrypting it correctly is very straight-forward. You should use AES-256 or another well-vetted encryption algorithm.

AES-256 has been vetted by security professionals for many years, and so far, there are no known attacks to shortcut the algorithm. ("Forced entry" is simply not possible.)

Implementation of AES requires a few things:

• A strong key. The key length for AES-256 is 256 bits. If you want a shorter key, then you can use a Key Derivation function. See my answer over here for some principal information on how bits of entropy works.

  • The key could be a 256 bit (32 byte) file.

  • The key could be derived from a 72-bit secret using a Fast Hash. (SHA-256, etc)

  • The key could be derived from a password using a Slow Password Hash. (BCrypt, PBKDF2, scrypt, etc)

    A more complex password will absolutely produce a stronger key. Slow password hashes simply multiply the difficulty of brute force to a certain extent.

• A good chaining method. AES is a block cipher. If your message is very long, you want to make sure that your chaining method will hide any patterns. For example, here is what an encrypted image looks like when you neglect to include a secure chaining method. Much of the data was lost, but much of it is still recognizable!

• An Initialization Vector is useful so encrypting the same message always produces a different result. (so attackers cannot detect duplicates after encryption)

A proper implementation of AES that includes the above items will be so difficult to crack, that the attacker will shift focus to other avenues, such as key theft and phishing.

These are sound algorithms that the world relies upon, if properly implemented, the attacker will not be able to decrypt your data without first stealing the key.

It is true that there could be a technological breakthrough that rocks the encryption world as we know it today, but this is unlikely to happen for a long time, given how long professionals have been trying thus far.