Key derivation from a random seed

Question

The main problem is to use a block cipher to generate a random key.

I would like to generate 256-bits key which can be as random as possible. I generate it in the following way:

1. Pick a plaintext $p_0$ of 64 bits and a 256-bit key $k_0$. ( can be given from keyboard as seed)
2. Implement a cipher which goes from 64-bits to 64-bits.
3. Encrypt $p_0$ with this cipher using $k_0$ to get $c_0$. (Assuming that the cipher is a pseudo-random permutation then $c_0$ is pretty random)
4. Set $p_0 = c_0$ and repeat the process say for 1000 times.
5. At the end use the last 4 encrypted messages of the loop to fill the key $k_0$ and take this as the new key.

Is this method random enough? Maybe there is a problem as I'm using all time to encrypt $k_0$? Which is the best implementation to get a really random key?

Answer 1

What you are describing is called output feedback mode, a mode of operation for block ciphers to create a stream cipher. You are discarding the first 996 output blocks and are using the following four ones.

In general, your algorithm (as any algorithm) can't produce randomness, just stretch existing randomness in a way which might look more random.

If there are $N$ possible values for $p_0$ and $M$ possible values for $k_0$, we get at most $N·M$ possible different values for the final key – no algorithm can do better, arguably.

If the key $k_0$ is fixed (or known to the attacker), she can just as well as you calculate the whole series and get the result from $p_0$ (or even, if she had only one block of the output, calculate $p_0$ and the other blocks of the output).

The moral: don't try to invent your own scheme.

For deriving a key from another, already high entropy key (e.g. to use different keys for different uses), use a key derivation function. Those are often based on a MAC or a hash function, use the key and a "personalizer" as input, and create another key.

For deriving a key from a password (i.e. a low-entropy key which a human can memorize), we want a slow key derivation function. These take a password and a salt (different for each use, but doesn't need to be secret), do a lot of work(configurably much), and produce a key. Examples are PBKDF2, bcrypt and scrypt.

Answer 2

You should be using PBKDF2. It is designed for exactly this purpose. Don't design your own when there exists a standard, well-vetted scheme.

But really, in most cases you should not generate cryptographic keys from a human-entered password or passphrase. Such systems are usually insecure, given how users tend to work in practice. See Try to avoid using passwords as encryption keys.