# Is a single md5 hash a good way to generate an AES key?

This site says how to encrypt data using a password in go using AES-GCM.

It says the following:

When encrypting and decrypting data, it is important that you are using a 32 character, or 32 byte key. Being realistic, you’re probably going to want to use a passphrase and that passphrase will never be 32 characters in length.

To get around this, you can actually hash your passphrase using a hashing algorithm that produces 32 byte hashes. I found a list of hashing algorithms on Wikipedia that provide output lengths. We’re going to be using a simple MD5 hash. It is insecure, but it doesn’t really matter since we won’t be storing the output.

Is this true?

So fine, I don't mind using something a bit more secure than MD5, it's easy to replace MD5 with SHA-2.

But another thing hit me:

• Why is something like bcypt/scrypt not required?
• Is AES slow enough to prevent a brute-force attack?
• Characters and bytes are not the same thing since the disco era, and MD5 output is 128 bits which is 16 bytes assuming common (but not universal) 8-bit bytes; it is sometimes represented in hex as 32 characters but that is not the same thing, and misunderstanding that suggests low competence. Although a good PBKDF (not a simple hash, see answers) of 128 bits would be fine, barring maybe quantum. – dave_thompson_085 Nov 23 '18 at 6:32

Assuming that the password/phrase is in fact a password/phrase, and does not already contain sufficient complexity to prevent guessing (e.g. is not a cryptographically strong random string)...

Is this true?

No. An attacker will simply guess at the password, and a fast hash function will help them to guess faster. An attacker can try a truly ridiculous number of md5 hashes per second, and will certainly break any password/passphrase that was not generated to be cryptographically strong.

Why is something like bcypt/scrypt not required?

Slow hashing is required, and the information in the article is not good advice. Choosing MD5 because it offers the right digest size out of the box is not justifiable: Stronger 256-bit hash functions exist (e.g. SHA256), and a larger hash digest could easily be truncated down to 256 bits

A cryptographic hash function is not appropriate for use on passwords/passphrases.

Is AES slow enough to prevent a brute-force attack?

No, and it is not the ciphers responsibility to be slow to prevent brute-force attacks on the key. Assuming that they key is strong enough to be called a key (e.g. a uniformly random bit string), then having a slow cipher is completely non-productive.

So the responsibility for being slow to prevent guessing attacks falls to a step before encryption takes place, namely, the key derivation step. Functions such as Bcrypt/Scrypt/Argon2 are explicitly designed for the purpose.

## Alternatively

If the passphrase was generated randomly and designed to possess sufficient entropy, then using a slow key derivation process is not really necessary or beneficial. In such a case, using something like HKDF would probably be the most appropriate.

## In any case

Selecting MD5 from a list because it seems fine is not a good sign...

• I believe you've missed a point.. It's not MD5 for a password, it's using an MD5 hash as a key to AES. You can brute force raw bytes faster than you can brute force any hash, and since the guarantee is coming from AES, not MD5, I don't think MD5's speed is a limitation. [Whether AES is appropriate you've covered] More significant IMO (and why I was googling this question) is whether or not MD5's weakness WRT collisions would mean more valid keys. My use-case is wanting to hash a file contents to use as a key and I'd prefer not to waste cycles on something cryptographic if not advantageous. – Basic Oct 10 at 20:48

Is this true?

Although as the author says that the hash is not stored and there is no preimage attack on MD5, the problem with MD5 is; it is very fast, that is a brute force on the passwords can be executed 4 times faster than SHA-1 and 30-times from SHA-3. If we assume that we have a plaintext-ciphertext pair we can search the passwords very fastly.

Why is something like bcypt/scrypt not required?

Required because; Bcrypt uses a configurable iteration count so that you can reduce the speed of passwords search. 10 iteration, 10 times slower, 100 iteration 100 times slower, etc.

Is AES slow enough to prevent a brute-force attack?

Interestingly, we actually require fast and secure block ciphers. AES is not slow, the problem is the key size and even the minimum $$2^{128}$$ is infeasible for a brute-force attack.