Let me start off by saying I don\'t know very much about encryption, hashing, cr

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.

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse L
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.