Are salts and password hashing needed for random keys?

Question

I know that salts protect against rainbow tables, and I also know that hashing a password a certain number of times increases the strength of encryption, with more times of hashing being better.

But are salts and hashes really needed if you have a truly random key and not a password entered by a user? For instance, suppose the password is a "ridiculously" long string of random printable (or better yet, pure binary) characters, for instance 256 random bytes for an AES256 cipher.

Does it matter how the cipher is used? For instance, one use might be to encrypt the contents of a file with the random key, and another might be to use it as a stream cipher to encrypt some kind of communications. Assume in all cases that in addition to being random the key itself is secure (e.g. never transmitted on an un-secure channel).

Answer 1

You seem to be mixing different use-cases here. One use-case is obtaining an encryption key from a secret. The other is storing login data.

If you need to derive an n bit encryption key for a symmetric cipher as your AES example suggests, the best you can hope for is n bits or entropy. If you have a true random source and use it to generate all n bits independently, that's the maximum possible entropy. Hashing your data at best won't decrease the entropy.

If your input is a user-provided pass-phrase, a key derivation function has to be used to condense the entropy of the arbitrary length string into the number of bits expected by the cipher. A simple hash function can be used as a key derivation function but it won't be very secure. User's pass phrases often have very poor entropy. The goal is to make the evaluation of the key derivation function so expensive that attacking the pass phrase is no more efficient than directly brute-forcing the key bits. In your case, the identity function already provides this property, however.

A different use-case is storing login data in a database. Here, hashing and salting is not used to “make the passwords more secure” but to make it hard to guess the actual password even in the case that the attacker gets hold of the database. If the database contains the passwords in plain text, it doesn't matter how long and random the password is. The attacker can always read it directly.

Answer 2

You should take the following motto to heart: passwords and cryptographic keys are not the same thing. Some contrasts:

• Passwords are chosen by human beings with their brains, but keys are generated randomly with a secure generator.
• Passwords are alphanumeric, but keys are binary.
• Passwords are variable-length, with humans choosing the length individually. But keys are fixed length, with the system choosing the lengths.
• Passwords are human memorable, but keys must not be so, and are instead stored securely.
• Passwords are a "something you know" factor, but keys are a "something you have" factor.

But are salts and hashes really needed if you have a truly random key and not a password entered by a user? For instance, suppose the password is a "ridiculously" long string of random printable (or better yet, pure binary) characters, for instance 256 random bytes for an AES256 cipher.

The short answer to your question is that keys don't need password hashing, but the problem here is that you're talking about passwords and keys as if they were interchangeable, and that's a red flag. If your encryption program allows the user to type in variable length alphanumeric passwords of their choice, then that program really needs to apply a resource-intensive key derivation function to the user's chosen password. If the user chose a really strong password all that slow hashing would not be necessary, but a password-based encryption program must assume the password is weak.

Conversely, if the program is designed to use strong cryptographic keys, then it shouldn't allow the user to choose them with their brain or input them with their hand. It should support these options:

1. Generate a strong key and write it out to a file.
2. Use a key stored inside such a file.
3. Use cryptographic smart cards instead of files.