Would it be secure to generate random number using AES?

Question

I know that there are already tools out there to generate cryptographic random number, but I was wondering if using AES could do the same.

For example, I have a secret key for AES on my server and a counter in my database. Each time I want to generate a random number I increment the counter then encrypt it with AES using the secret key on my server then transform the resulting bits into the right number.

Wouldn't this produce secure random number as long as my secret key is not found?

N.B.: If you want to say that storing a password on your server is not safe, please explain how it is different than storing your private SSL key on your server.

Edit

Found some info on wikipedia

A secure block cipher can be converted into a CSPRNG by running it in counter mode. This is done by choosing a random key and encrypting a 0, then encrypting a 1, then encrypting a 2, etc. The counter can also be started at an arbitrary number other than zero. Obviously, the period will be 2n for an n-bit block cipher; equally obviously, the initial values (i.e., key and "plaintext") must not become known to an attacker, however good this CSPRNG construction might be. Otherwise, all security will be lost.

So, it was used before to construct CSPRNG.

Answer 1

What you are describing is a custom, AES-based PRNG. Encrypting successive values of a counter with AES and a secret key is a sound method for building a PRNG (indeed, it is equivalent to encrypting a long sequence of zeros with AES/CTR), provided that you take care of the following:

• You have to use the block cipher "as is": encode the counter as a single 16-byte block, process it with AES (no "block cipher mode"), get the next 16 pseudorandom bytes. Increment the counter, and loop.

• This won't be stronger than the encryption key is secret. Keep the key safe !

• Of course this assumes that you already have a secret key, which implies that some other cryptographically secure PRNG was used at some point. A PRNG does not create randomness, it expands some initial randomness (the "seed", here the AES key) into a long stream of pseudorandom bytes.

• This PRNG relies on your never reusing a counter value. So you have to make sure that the counter is always increased and cannot be forced to "rewind". This is not as easy as it seems, in particular in embedded devices, where read-write permanent storage is at a premium, and the user (who may be the attacker) can force hardware resets at any time (by removing the battery).

• AES being a block cipher, it is a permutation of the space of block values. As such, it won't ever output twice the same 16-byte block, which deviates from what a true random source would produce. This may begin to show (statistically) after about 2⁶⁸ bytes, which is high enough not to be an issue. However, think twice before trying the same trick with a block cipher with smaller blocks (3DES, Blowfish...).

An improvement may be to regenerate a new AES key each time the server starts up, using /dev/urandom. That way, there is no key to store anywhere. Indeed, there is no need to reuse always the same key.

(Arguably, it is even simpler to use the strong PRNG which is already there, e.g. /dev/urandom. Switching to a custom PRNG like the one you envision is quite unwarranted; unless you need pseudorandom bytes at more than 10 megabytes per second, which may happen in some cases, but is weird. If you are in need of lots of pseudorandom bytes, you may want to consider using other more specialized algorithms like these stream ciphers.)

Answer 2

Theoretically, yes, but there are practical concerns.

As a pseudorandom number generator, it works well enough. But to make a CSPRNG out of it, you would need to start with a cryptographically-secure random key... and to get a cryptographically-secure random key, you need a CSPRNG. This is a chicken-and-egg problem: in order to build a CSPRNG out of AES, you need to already have a CSPRNG.

Why would you do that? In most circumstances, it wouldn't make much sense: if you've got access to a CSPRNG to make your key, then you might as well just use it directly. However, there are still cases where it can be useful. For example, if you're coding in a situation where you don't have access to a CSPRNG, but you do have access to a secret key which was made with one (and you know that this key has been kept secure), then you could use AES to make cryptographically-secure random numbers from the key. The implementation issues mentioned in other answers still apply, though.

Answer 3

I think that the output should seem pretty random indeed. But it is, however, very predictable id your private key is known. So the numbers generated have very little entropy. I would call the result a PRNG but never a SPRNG or a CSPRNG.