Say I want to create many random AES keys and have access to a secure source of random numbers SecRand.

I see two extremes of how I could write a key factory.

Use the same random source for all keys:

KeyFactoryA {
    private r = new SecRand()

    makeKey() {
        // create a key using r

Use a new source for every key:

KeyFactoryB {
    makeKey() {
        r = new SecRand()
        // create a key using r

I remember from statistics lectures (different field, I know) that the aggregate stream of random bits used in B would not necessarily be uniformly random; that is, B would be statistically weak. Also, it requires a larger pool of entropy to initialize all the different r.

A, on the other hand, may create many keys from a small initial pool of entropy. That does not sound too good either.

Are there any security-related differences between the two options?

1 Answer 1


What you want for your key(s) is to be completely unpredictable.

There are now three cases to distinguish which really depend on your "secure random" class / object.

  1. It starts with high entropy and then drops. If your source of entropy is really good, this shouldn't happen, but if it does you may either use a new instance (like you did in B) or you instantiate what cryptographers call a pseudo-random generator (PRG, ie a strong stream cipher encrypting zeroes) using your high-entropy input and use the resulding key stream as continuous source of computationally unpredictable key material. Note that if you use the output directly that the output must be uniformly random which means that if you use a direct physical effect or some gaussian-sampling RNG, you really should securely hash the output of the RNG and then feed it into a PRG which will remove all potential bias.
  2. It starts off badly and then increases in entropy over time. In this case you want to take the entropy you gain over time and condense it into a short-highly unpredictable string using a secure hash function and use that to instantiate a PRG.
  3. It's always a good source of uniformly random numbers. In this case it doesn't really matter which approach you follow, eg using only instance forever, spawning many new instances or using a PRG, all of them should be fine.
  • Thanks! I'm looking at Apple's CommonCrypt (the recommended DRBG of which does what you propose in 1 afaict) and Java's SecureRandom (the same?). So if I use those as primitives, from my perspective I'm in case 3. Did I get that correctly?
    – Raphael
    Jan 26, 2017 at 11:13
  • @Raphael yep, those two claim to be CSPRNGs and thus you're indeed in case 3 :)
    – SEJPM
    Jan 26, 2017 at 11:17
  • Phew, that's a relief: smart people have done all the thinking for me! What a luxury. :D
    – Raphael
    Jan 26, 2017 at 12:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.