# Why brute-force the password instead of the key directly?

This answer on another question on security stackexchange by a very reputed user explains why he prefers GnuPG over OpenSSL for file encryption. From what I understand, it can be summarized as this:

When using OpenSSL, the encryption key used is derived from MD5(password+salt) with only one iteration. So it is easy for an attacker to brute-force the password and get the encryption key.

My question is: Why would an attacker want to brute-force the password instead of the key directly? For example, if the key is 128 bits long and my password is 16 characters long (128 bits), my (password+salt) is already longer than the encryption key. This means that is would actually be easier to brute-force the encryption key directly instead of the password and the number of iterations in the Key Derivation Function is irrelevant.

But the answer given above is often linked as a reference on many other similar questions and it is from a reputed user. So where is the flaw in my reasoning?

• It seems like your core question is about brute-forcing password vs key, not about GPG vs OpenSSL. I am going to edit the question to make this more clear. Feel free to revert the edit if you don't agree. Aug 20, 2017 at 22:04
• The answer referenced in the question also addresses a very specific method of encryption available with open_ssl and hence irrelevant to any comparison of the wider merits of the 2 packages. The bear says he prefers pgp for symmetric encryption. Aug 20, 2017 at 22:09

## Brute-forcing the key vs brute-forcing the password

### Brute-force the key

To brute-force the key directly I need to keep guessing keys and attempting to decrypt the encrypted file with it until eventually the file decrypts properly. Without any extra information, I need to try the 2128 possibly key values at random.

On average I will need to do 2128 / 2 = 2127 guesses. By the way, this is a massive number! Physics reduction: one ARM assembly instruction (ADD, SUB, XOR, ...) consumes about 300 pJ ~= 3.0x10-10 Joules per instruction on a low-power embedded device. The sun contains roughly 1.2x1044 Joules of nuclear fuel. Assuming we could guess a key and try decrypting the file in a single ARM instruction (which is bananas, you're looking at millions of instructions for a reasonably-sized file), then doing this brute-force attack would require consuming 2x1015 stars! Yeah, 2127 is a massive number. Good luck with that brute-force attack. Hope you have a good electricity rate.

### Brute-farce the password

The length of the password is only relevant insofar that a 16-char password has more possible combinations to guess over than an 8-char password. While your 16 character password may require 128 bits of disk space, it is certainly not 128 bits of security. For starters, there are only 95 printable ASCII characters, so for a password that only uses keyboard chars (no accents, emojis, etc), at best you're looking at 9516 ~= 2105 possible 16-char passwords to guess. On top of that, we know that 30% of accounts on the internet have a password from the top 10,000 passwords [source], so the length is actually irrelevant if you're one of those 10,000.

## Putting it together

Brute-forcing the password, if this is some random internet user (ie they are inventing their passwords the way the average internet user does), then you have a 30% chance of cracking it in the first 10,000 guesses. If I'm brute-forcing the key directly (without using any extra knowledge), then I have a 0.0000000000000000000000000000000003% (3x10-35) chance of cracking it in the first 10,000 guesses.

Basically, passwords are weaker than keys because human brains are stupid and predictable. If your password came from a random generator, then this is a completely different story because it's really more of a key than a password.

• Thank you! I was confused because the linked answer and the comments make OpenSSL look really bad in term of security, but it is not as bad as described. GnuPG is better than OpenSSL precisely because the KDF is slower? But, with a strong enough passward (from a random generator for example), they are equally as secure? Aug 20, 2017 at 23:41
• I don't know what GnuPG does, but I would assume it uses a more modern KDF that's slower. For the second question: password managers use KDFs internally to generate "random passwords" so yes, for the purposes of this question, a random password and the output of a KDF are equally secure (formally: both string have equal entropy. You could argue that with a strong password, the slow hashing is done once by the encryptor, whereas with a KDF in the alg, slow hashing is done by the decryptor too and therefore also by the attacker on each guess. But we're getting into multiples of the sun...) Aug 21, 2017 at 0:02