# How secure will this be against brute-force attacks?

I'm looking into encrypting files like this: First, I SHA-1 hash the password. Let's say the password is something normal like "hello123", and then hashed. Then I encrypt a file using this:

openssl aes-256-cbc -a -salt -in file -out file.enc


(using the hash for the password).

So it's basically just an AES-256-CBC encryption with a salt.

How easy would it be to crack this by brute force? (Assuming the attacker knows that we have aes-256-cbc with salt and that the original password is hashed.) For instance, how long time would it take these days, on "normal" hardware?

• How is the password chosen and are there are requirements (length, special characters, etc)? Oct 25, 2012 at 14:35
• @mikeazo There are no requirements, but let's for the sake of argument just say the password could be 4-10 characters long (a-z, 0-9). I suppose most brute force attacks start with the shorter passwords, and work their way towards the longer ones? Oct 25, 2012 at 14:38
• Ok, now what is the attacker's goal? Say there are 100 encrypted files all encrypted with a different password. Does the attacker want to crack any one, all 100, or a specific one. Oct 25, 2012 at 14:51
• @mikeazo Just a single file. (Or many files with the same password.) Oct 25, 2012 at 15:03

I don't know how you're adapting the digest of SHA-1 to meet the key requirement of AES-256 (stretching the 160 bit digest into a 256 bit key), but if you somehow have a way of doing that without seriously compromising key entropy, then you have a theoretical key space of $2^{256}$. That window is limited by the limitations on your encryption passphrase however. In an ideal case for decryption where the person cracking your cipher has your program and knows the limits on your passphrases, they don't have to test all $2^{256}$, only your possibilities.

Say you limit passphrases to $10$ keys, alpha-numeric. That's $62$ characters to work with. The practical key space for you is $62^{10}$.

Arguably, it is currently impossible to decrypt even in the above worst-case scenario. This is largely due to another factor: verification of success. Say you only had $200$ possibilities. Someone trying to decrypt the file needs a way to check if each of the $200$ attempted keys yielded accurate results. Given that they may not know the nature of the file, that seriously complicates the process.

You're good for a while.

• In practice quite often the attacker has some ideas about the "nature of the file" – has a list of possible file headers, for example. This might complicate the work a bit, but not "seriously". (Also, there is no way to stretch an 160-bit hash into more than 160 bits of entropy.) Oct 28, 2012 at 20:43

It's really just the sum of the time it takes to execute both algorithms on that "normal" hardware. If you can test 100,000 SHA-1 iterations per second on the machine, and 50,000 AES256 decryptions per second, .00001 + .00002 = .00003, or 33,333 tests per second.

But there's a lot you didn't answer. How much keyspace are you willing to search? If the password is 1 alphabetic character, your answer will be virtually instant. If the password is 100 bytes long, the ashes of the universe will have cooled before you have recovered the password.

Your example features an 8 character password. If I know I have to test all 8 character alphanumeric passwords, that's 62^8 tests, or only 218 trillion attempts. If a desktop machine can test 10 million passwords per second, it will have searched the space in about 21 million seconds (252 days).

But who is attacking? What is their motivation? If it's a national security organization, their idea of a normal password cracker is different than yours. A criminal organization wanting to steal millions of dollars from a stock brokerage or a bank would certainly invest \$100,000 in cracking it quicker. They would likely farm such a task out to a botherder, who might assign 1,000 internet zombie machines to crunch away at the task, cracking it in a day or two.

• Another thing to consider is the randomness of the password. Oct 25, 2012 at 14:30
• @mikeazo, good point! A dictionary attack could yield a password based on a dictionary word in far less time. He did ask about brute forcing, but I completely forgot that he said the password is "something normal". Rules to apply to a dictionary, like the old Crack tool has, would give a huge potential advantage to the attacker. Oct 25, 2012 at 14:53
• If the 100 byte password is hashed with SHA-1, only the 20 byte hash remains, so one would only need to brute force the hash, not the original password. Oct 26, 2012 at 22:50

It depends. If your password requirements are weak, it's probably not too difficult to brute force given your weak key derivation (SHA-1). OpenSSL already does key derivation for you (the -salt parameter is a part of that), but if you wish to do it yourself, you should use something like PBKDF2 with 100,000+ rounds and a randomly-generated (for each file, if possible; otherwise, once) salt.

If you do this and pass the key into the command line with -K, however, you will also need to take care of the IV requirements of CBC, which require generating a cryptographically random string of appropriate length, sending it along with the -iv flag, and storing it alongside the file.

• So you could say that I was considering using first sha1 and then the "-salt". I suppose the former really is unnecessary. Whatever. But now, given that I use "-salt", does that make things secure? How many rounds does the built-in "-salt" do? Oct 25, 2012 at 21:17
• No idea. I couldn't find the key derivation function used by OpenSSL anywhere. If I were paranoid (I am), I would PBKDF2 it for 128,000 rounds using SHA-256 and a cryptographically-random salt of appropriate length to generate a key. Then I'd generate a unique, cryptographically random IV for every file I wanted to encrypt, and pass the key (not password and -salt), IV, and data in to the command line. Oct 25, 2012 at 22:22

This doesn't add anything. OpenSSL already provides a proprietary method of key derivation / key stretching. So you have added a single hash to protect the hash that is already performed.

OpenSSL's key derivation uses only one iteration by default. If you want to make the key derivation more secure, you should up the iteration count (or work factor). That is however not possible using the command line interface

You could either choose to patch OpenSSL or you could create your own program and configure PBKDF2 from that.

That all said, using a good password is going to help you much more than hashing a weak password and a large work factor. A really insecure password will stay insecure forever.

• EVP_BytesToKey isn't really proprietary: up to one hash block it is PBKDF1, and beyond that it's extended in the same fashion as PBKDF2; although not as good as PBKDF2 that's not very bad. What is awful is that when used by commandline enc without -K, and also for "legacy" (i.e. not PKCS#8) privatekey files, it uses ONE (1) ITERATION. Feb 13, 2015 at 21:03
• It's not a good thing that it extends like PBKDF2 as PBKDF2 requires the same amount of iterations for each block, giving the attacker more advantage over the user (if you want more derived data, I'd use a KBKDF in addition to the PBKDF1/2). Of course, that doesn't matter because of the single iteration, which is of indeed bad. Interesting to know that it is identical to PBKDF1 for one iteration, I'll remember that. Feb 13, 2015 at 21:09
• @dave_thompson_085 Altered answer as well. Feb 14, 2015 at 1:40

It all depends on your restriction of length of initial password. If your user is able to enter password of just 4 characters, then doing SHA1 etc is not going to add any entropy (in simple words the brute force space for the attacker is not going to increase). Assuming attacker can check One million password per second then below is a summary for your password lengths (password contains Alphanumeric and special characters)

This give you much confidence that attacker cant brute force with 10 more characters. But remember attacker is always going to bypass such brute force effort by using some other means like dictionary base password guessing or some weakness in your implementation, or even he can recover the password if you store it somewhere. So there are always otherways :)

This is easily cracked if you encrypt Bitmap Picture with CBC mode cipher since the 128 bits data block will be the same on bitmap pixels.

• This is not true: CBC mode does not have an issue with repeated plaintext blocks Feb 12, 2015 at 21:53