Securing AES 128 encrypted ZIPs against brute force attacks

Question

How long would it take to brute force decrypt an AES 128 encrypted zip file if the password is 8 characters long in the range of A-Z, a-z, 1-9?

Does it make any difference if .NET's System.Random object was used to generate the password or if System.Security.Cryptography.RNGCryptoServiceProvider was used?

I'm writing an application and I want to make sure I get the security right. In the worst-case scenario, if an attacker got access to the client's computer, he would have a few dozen zip files to attack but they all have the same password. I want to ensure that the application is secure against this kind of offline brute force attack. The attacker would not have access to any other randomly generated passwords or zip files encrypted with a different randomly generated password.

Answer 1

The correct math is, that with 26+26+10 characters and a password length of 8 you have a keyspace of 62^8, which is 218.340.105.584.896 or ~2^48.

Breaking this is feasible. (How long it would take is a complicated question, depending on the attackers budget, the implementation. With a good GPU one can probably crack it within a day.) You should use at least 12 characters, probably more. (This depends on who your enemies are, how much money they have, how long the data should be protected, etc...)

Also, as the OP suggested, password storage might be a weak spot/problem.

And using a crypthographic RNG is always a good idea.

P.S.: You can read more at:

• http://en.wikipedia.org/wiki/Password_strength
• http://en.wikipedia.org/wiki/Brute-force_attack#Theoretical_limits
• http://www.wolframalpha.com/input/?i=password+of+8+characters

Answer 2

System.Random is not cryptographically random (see http://msdn.microsoft.com/en-us/library/system.random.aspx). It's predictable enough to weaken your crypto considerably.

See Tie-fighter's answer below for the keyspace calculation (which I got hopelessly wrong by using 61^8 instead of 61^8)!

I'd be more concerned with how that password is stored. Surely your application needs to decrypt the zipfiles on the (potentially-compromised) computer in order to use them? Is the password to do this stored on the same machine?

Also, to throw a spanner in the works - surely your 'worst case scenario' is that an attacker gets access to the client's computer and watches the screen while the legit user does work with sensitive data?

Answer 3

You may want to consider using different passwords on each file (yes it's a pain but more secure).

Or you may want to consider using RAR instead of ZIP since RAR v3 does take longer to crack. Also both 7-zip format and RAR support AES256. Again it all comes down to how valuable the data is.

If you are super paranoid encrypt using RAR and then 7-ZIP the file with a seperate password.

FYI CRARK supports GPU clustering so if you have a house full of laptops an desktops with GPU's you could theoretically crack your passwords within a reasonable ammount of time (depending on the length of the PW) Again if super sensitive data use 2 passwords and 2 different formats with completely different passwords.