# Generating a cryptographically secure, many-time use, symmetric encryption key

I need to generate a 256 bit encryption key described by the adjectives in the title. Currently I intend to create the key using this RNG.

Is this a secure manner of creating the key, given that it has the following properties:

• Private key for symmetric encryption
• Used many times (of course with unique IV's)

And given the following facts:

• I will literally just get the RNG to produce 32 random bytes
• not doing anything with (1) SALT (2) Iterations (3) Anything else

Please note that I am only asking if the key, directly after being generated, is secure. Thanks

-

Short story: Ultimately, your question comes down to a question of the quality of the Windows RNG. Your approach is fine if your RNG is good, but you're trusting the largely opaque Windows RNG to give you a perfect 32 bytes of entropy. I would recommend generating more bytes and then using a hash or KDF to compress it to 32 bytes.

Slightly longer story: All good random keys are generated from the same principle: An $n$ bit key is generated from a source providing $m$ bits of output with $n$ bits of entropy. If the source is high quality entropy output, then at best $n = m$ and the direct output can be used as a key. Otherwise, you would use something like a hash or a KDF to compress the $m$ bits of entropy to an $n$ bit key. Pick a good entropy source, and the random bytes it outputs will be a good key.

In your case, you are using the recommended cryptographic RNG provided by your host OS. This seems like a reasonably secure RNG source, but in general we like to be cautious about these things since there are many practical things that can go wrong. Since Microsoft doesn't publish the details, by default we tend to have more skepticism about it. A series of low entropy bytes might be output, the RNG might be badly constructed and a compromise of our key might lead to a compromise of the system's RNG state and thus future or past keys, and other such problems. To mitigate these failures, generally good practice is to pass RNG output through a hash or KDF before turning it into a key (even if $n = m$).

The Windows CryptGenRandom API is another portal into the Windows RNG, and I would think would work very similarly to the .NET call you referenced. Note that it has been at least in part reverse-engineered and had a few attacks against it, although I don't think low entropy itself is one of them.

-
Acquiring more entropy than you need from a number of sources and then using a cryptographically-secure hash of everything you've collected is cheap insurance. Your result will be at least as strong as the weaker of its strongest input and the hashing function. –  David Schwartz Jul 24 '12 at 6:48
I decided to instead use the .net AesManaged class and simply extract the key it creates under the assumption that that key will be at least as secure as the above method –  crawfish Jul 24 '12 at 16:09