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

Question

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?

Answer 1

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...

Answer 2

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.