Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Our application needs to generate secure keys for long term storage on AWS using openssl. But I've seen some instance where entropy falls dangerously low on AWS machines and this doesn't appear to be 100% safe. People have reported low entropy in some situations.

What is the easiest way to ensure you are generating strong keys on AWS?

For example, is there a way to:

  • block execution until there is sufficient entropy as a fail safe
  • seed machines with more/higher quality entropy
  • supplement AWS with some other piece of hardware to provide a good source of randomness

I've seen but using an external web service doesn't seem appropriate or fast enough for a production environment.

share|improve this question
If your plan on keeping the key active for a long time, you shouldn't concern yourself too much about how fast your key generation system will be: if you need 5 additional seconds to create a key that will be secure for 5 years, that's insignificant. – Stephane Oct 22 '13 at 8:43

This "low entropy" mantra is a dud. See this answer for details. The executive summary is: some software, in particular /dev/random, may report a "low entropy" and block for reasons which make no practical sense. The idea of entropy being "exhausted" comes from a mathematical model which has only tenuous links with reality, and may (theoretically) provide any security gain only when the randomness is used for "information theoretically secure" algorithms. Usual algorithms such as RSA or AES are not of these class.

So what you need to do is the following:

  • OpenSSL should normally use /dev/urandom, avoiding the problem. If the problem occurs, it will manifest itself as a "blocking" behaviour (key generation takes an abnormal amount of time, with no CPU used).
  • If the problem occurs, "refill" /dev/random with fresh pseudo-randomness, which is good enough. Something like: dd if=/dev/urandom of=/dev/random bs=1024 count=64

There is, however, another issue which is not so easy to deal with. Cloud systems are virtual machines, which may run concurrently with other virtual machines on the same hardware. When two execution threads run on two cores of the same CPU, even if they relate to distinct virtual machines, they share the level-1 cache and may potentially spy on each other. The technique involves doing memory accesses in an array which uses the same cache lines as the target code, and reconstructing the target secrets by noticing when some array elements have been evicted from cache.

Working prototypes have been demonstrated in lab conditions. Whether they may be applied in a practical setup depends on a lot of parameters, and is currently unknown. However, it is plausible. The conclusion is that if you do something serious with keys, then you should strive to run on your own hardware, or at least obtain some guarantee from the cloud provider that your virtual machines will not share the same hardware servers as virtual machines from other customers.

share|improve this answer

There is a lot of misconceptions and myths about /dev/random or /dev/urandom. It's not true in general that using /dev/urandom is always good enough and that /dev/random is for paranoid only.

The key here is the total amount of entropy collected during the lifespan of the instance before you start to generate numbers. That's what matters most. After instance spawn (from AMI) the random generator needs to accumulate enough entropy to start producing un-guessable numbers.

Once there is enough entropy, you can generate pretty much "any" amount of data that is crypto-strong from /dev/urandom. If the entropy collected is not enough however, then there is no other solution than to get it first.

That /dev/random reduces the counter of entropy is little bit paranoid. It is a must-have properly of a good rnd generator that you cannot guess next generated number even if you publicize any amount of previously generated numbers. To achieve that, generators use eaxctly the same constructs you find in encryption algorithms (AES, SHA, etc.). Therefore if you don't believe in your rnd generator you cannot believe in your encryption as such.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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