# Securing AES 128 encrypted ZIPs against brute force attacks

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.

-
I believe you mean 0-9, not 1-9. –  Tie-fighter Jul 2 '12 at 21:18
No I really did mean 1-9, in the current implementation. –  John Jul 3 '12 at 0:28

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:

-
You can really crack an 8 character alphanumeric AES password in a day with a graphics card? Can anyone confirm this? How come this poster security.stackexchange.com/a/16756/10574 claimed that 8 characters was secure? –  John Jul 3 '12 at 0:30
In 2008 we (university) did ~400 Million per second on a single machine which correlates to around ~133h for your keyspace of 61. (Keep in mind that this is the worst case.) That was in 2008 (Moore's law). Considering that we live in 2012 now and there are theoretical attacks on AES, I personally would go with the full 128bit. Concerning the OP: I don't know why he claims that. –  Tie-fighter Jul 3 '12 at 12:04
Would it be better to use PBKDF2 to key stretch a 12 character alphanumeric password? –  John Jul 3 '12 at 13:51
Yes, that is a good idea. Thb I never looked into PBKDF2, but wikipedia and other questins suggest that scrypt is an even better alternative. –  Tie-fighter Jul 3 '12 at 14:16
I only know the stats for SHA-1: ~400 Million per second on a machine worth ~1,5k €. We used CUDA. (But once again, this was 4 years ago. Back then there was no Amazon cloud with Tesla cards.) Today I would probably use a cloud, just like this guy in 2010: infosecurity-magazine.com/view/14059/… –  Tie-fighter Jul 4 '12 at 15:13

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?

-
I moved away from ZIP storage for the exact problem randomdude brought up: people generally will know these passwords, and they're hard to reset. Moved to a public/private key system, private key never leaves server, new public keys could be pushed if we really wanted to with little effort if someone really screwed up and leaked the private key, but there are many fewer hands with access to it than the ZIP password. –  StrangeWill Jul 2 '12 at 17:39
@randomdude Could using System.Random weaken the crypto even for just one 8 character password they're trying to crack? I want to store the ZIP file password in an AES-encrypted configuration file using a key generated by PBKDF2. The key will be generated using the password the user picked. –  John Jul 2 '12 at 17:47
@StrangeWill where does the data reside and do they have to be connected to the internet to authenticate? This application will need to be able to authenticate offline. –  John Jul 2 '12 at 17:48
@John I don't know enough about System.Random to give a definitive answer. Is there any downside to using the cryptographically-secure RNG instead, though? I would definitely err on the side of caution here. –  randomdude Jul 2 '12 at 18:29
Your math is flawed :/ –  Tie-fighter Jul 2 '12 at 23:18

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.

-