Is there any defense against Brute-Force done on a local encrypted file?

Question

Let me start off by saying I don't know very much about encryption, hashing, cracking, etc. I'm just a typical computer enthusiasts, programmer and researcher with many questions.

So, I've discovered that there's a thing called "Distributed Cracking" which is when many systems cluster together to focus-fire a Brute Force processing on a single target.

I assume, in the case where the target is a local file on a computer, with enough time and resources, Brute Force has a 100% success rate. Please correct me if this assumption is false.

The only dependent object in this system is the software used to decrypt the encrypted source file. Brute Force has to go through this program to decrypt the contents.

Is there anything the program can do to defend against Brute Force? Could the program maybe destroy the targeted encrypted source file, and then self-destruct if the number if subsequent login attempts exceeds some ridiculously high number? Though, this will require that the program keep a running count of how many failed attempts there have been, which can be spoofed... It has to write and read the value from somewhere. That or the self-destruct feature can just be completely removed in a cracked and recompiled version.

I can't think of anything that would work.

If all else fails, does just having a ridiculously long password help at all? Something like 500-characters? I guess it should still get cracked. It'll just take exponentially longer. But just adding more cracking botnets to the equation can nullify that.

Answer 1

If the file is retrieved from the filesystem to the attacker's system, there is no longer any gateway. The brute force can continue without any impediment.

More complex keys or passwords do increase the time/cost of brute forcing, but 'eventually' (hopefully before the heat death of the universe), it could be cracked.

Answer 2

The only defense you can have on a locally encrypted file is the strength of the password used to encrypt it. Also, using a secure encryption algorithm is important (AES is pretty standard right now).

You are absolutely correct that brute-force cracking is 100% successful. The problem lies in the amount of time it takes to crack a password. A secure password will be very long and use a combination of upper and lower case letters, numbers, and symbols. In doing so, you give the attacker a keyspace of 96 characters. Let's say you use a 32 character password. That would total to 2,708,192,040,014,184,559,945,134,363,758,220,403,329,915,059,847,434,832,829,218,816 possible combinations of 32 character passwords.

Another factor is how fast a computer can generate each password when bruteforcing. On my computer, I can generate about 50,000,000 MD5 hashes per second. Likewise, for WPA (wifi) keys, i can only generate about 2,000.

Your idea of having a program with a "self destruct" feature when too many passwords are tried is a pretty weak form of security - much weaker than a password. Take for example the disk encryption software, Truecrypt. With truecrypt you can create encrypted file containers. However, there is software out there that is specifically made for cracking truecrypt encrypted volumes - without ever using the truecrypt software. The same can happen for your theoretical program as well.

So in the end, the best security for a locally encrypted file is to have a long password with a mix of characters and to use a standard encryption that is deemed secure by the community.

Answer 3

The issue is that there's no reason an attacker has to use YOUR program to perform the decryption. In fact, for increased speed, attackers almost always write custom programs to brute force, not the original program used to encrypt. They can do this because virtually all reputable encryption programs, even proprietary ones, use established and widely known algorithms to perform the encryption. This makes it easy to write a custom program to decrypt rather than use the original program. Thus, any brute-force protection in the original program would be useless.

You might be thinking, why not come up with a custom encryption algorithm, or make some tweaks to existing ones, and keep the program closed-source to prevent people from writing their own decryption programs? The main reason this is a bad idea is that secure algorithms are hard to come by, and tweaking well-established and tested algorithms is dangerous - it's VERY easy to accidentally introduce a backdoor. Plus, it's security through obscurity, which is generally frowned upon. Eventually, someone is going to reverse-engineer your program eventually and figure out what tweaks you've added, making these measures useless.

So really, no software measure can completely protect against brute force attacks (theoretically speaking). Practically speaking though, a long passphrase and computationally intensive algorithms can make it utterly unfeasible for even the most powerful supercomputers.

You CAN have data erased after x tries but, you have to implement that on the hardware level - ie, engineer the hardware to make it impossible to get a copy of the encrypted data without unlocking it first. Then add tamper-proofing measures to the hardware. I believe some high-security flash drives, like Ironkey, are capable of doing this.

Answer 4

I'll start with saying that you're right, eventually brute force would crack any encryption scheme. The eventually could be millions of years in the future though, depending on the complexity of the encryption key, the strength of the encryption, etc. There are actually a few defenses against offline attempts to crack a password file that are generally considered best practices.

Since you say you are not clear on how passwords and hashing works, I will give a brief outline of this which also applies to encrypting data in general. I'm sure you've heard people mention cleartext passwords being a problem. The solution to that is using a hashing algorithm.

There are three key parts to any password hashing algorithm. It should always result in the same hash with the same text being produced. It should be computationally expensive to calculate. It should be 1 way or you would have the same problem as the cleartext password list. Once hashing started to become popular, attackers quickly adapted. They would generate hashes of commonly used passwords, known as rainbow tables and then just match these hashes to hashes in the database. This is much less computationally expensive than calculating each hash on the fly, as these hashing algorithms are deliberately slow.

The assumption you have to make is that your password database may eventually be stolen by an attacker.and the longer it takes for them to crack it, the more likely you can detect their attack and reset your credentials. This is also a reason why 90 days is recommended for password rotation, since it reduces a window during which those credentials are usable. Anyway, I'm going to outline the basics of these defenses so you can continue your learning on this topic and bold specific words that are of specific interest.

First of all, any password database encryption scheme should include a salt. An example of a password encryption scheme that includes a salt is bcrypt, which is a good baseline of what to look for with anything performing this function. A salt is generated for each password and helps prevent an attack using rainbow tables. Rainbow tables use a list of precomputed hashes, and a salt makes this impractical to store on disk because of the sheer size requirements.

There are also ways you can make it make it hard to calculate each hash. This causes each lookup to be slower, but it's still fast enough it doesn't bother users. It just makes a brute force attack much slower. bcrypt again is a good example of this.

The third one is the most commonly known defense, password best practices. It seems fairly mundane, but it can help ensure that any attacks based on using common password dictionaries will fail and that much, much slower bruce force techniques need to be used.