Interesting question came up on an internal database security alias that I thought should be shared.

The question posed on behalf of a database customer was around seeding random routines. Was it more secure to provide a seed to the random number generator routines or not? The question was extended to say that if seeding the routines was more secure, what new security issues were introduced in storing the seed values used? To seed or not to seed, that is the question.

In this particular case, the answer is NOT to provide the seed the database random routines in production. Seeding is similar to the cryptographic concepts of salts and even nonces, but within databases, it is used slightly differently. In the Oracle DB world, generating a random numbers are the domain of the DBMS_RANDOM package. It specifically states it should not be used for cryptography.

Like salts and nonces, a seed is used to add some increased entropy to the generation of random values. Computers, for all their advanced capabilities, are still psuedo-random generators, not pure random generators. Given the same input, they will generate the same output. So to add some additional complexity to the random number generation to make it appear more a true random number, the DBMS_RANDOM routines allow the developer to “seed” any random number calculation. So one would think adding a seed to the generation would make the overall system more secure because the seed would better enhance the randomness of the pseudo random generation.

But, by supplying this seed to the calculation, the developer now introduces an added security complexity. Where to store the “seed” securely between calculations? It is in effect a secret key if used (inappropriately I might add) to encrypt or protect information in the database. Even with the documentation saying to do this, we have seen this done again and again.

What most developers miss is the DBMS_RANDOM package is a random package, not an encryption package. If one does not supply a seed to the random number generator, the routine creates a random seed on its own, based on userid, date, and process id. Not a truly random seed, but does add some entropy to the random generation.

In fact, the reason the routines allow the code to pass a seed instead of random generation of the seed is to allow testing. By passing the same seed to the random number generator, you get the same random number back, which allows testing across runs. As long as the seed remains fixed (non-null) the random number generator will pass back the same number. So, the thought that adding a seed to the random number generator to improve randomness actually fixes the generator to producing the same number, not a random one. Plus, you have a security problem of where to store the seed.

So the answer is NOT to seed the routine in DBMS_RANDOM, but let it generate its own “random” seed when called. Remember, this discussion is around this implementation of one random number generation routine in an Oracle database package and should not be applied to other random number generation routines. But be dutiful of the seeding documentation. Also, be aware that if you are using random numbers to do cryptographic encryption, you need to be sure the random routines are strong enough to insure the resulting security is trustworthy. You need to use cryptographically secure routines. Not all psuedo-random routines are designed with that in mind.

## Leave a Reply