Open Stack

Excerpts from Jarret Raim's message of 2014-01-13 15:57:50 UTC:
> All,
> 
> 
> I¹d be concerned about making this change. Fundamentally, the os
> /dev/urandom is cryptographically secure while creating a
> cryptographically secure PRNG is actually quite difficult, especially one
> built on PyCrypto which is a non-verified code base.
> 
> In the case of /dev/urandom, it seeds from the internal pool that also
> supplies /dev/random. Once this seeding is complete, urandom can be relied
> upon to supply random data without blocking or exhaustion problems. The
> only time when there could be an issue is shortly after boot before the
> kernel has generated enough entropy to sufficiently seed urandom.
> 
> This problem seems unlikely to appear in most OpenStack deployments and is
> the same problem one would have to solve to adequately seed the PyCrypto
> PRNG anyway.
> 
> Barbican has been thinking about exposing a /random resource that would
> allow any user (no auth required) to pull a block of truly random data
> from the HSMs for any case where someone would need it. We¹ve been on the
> fence as the actual use cases seem nonexistent at the moment, but it is an
> option for the future if we need it.
> 
> In short - we can probably leave the code the way it is.

Agreed, this is not a code bug. The description contains a false
assumption:

"On Linux, random.SystemRandom reads from /dev/urandom which if I
understand things correctly, can have its entropy depleted."

This is not the case, and the u in urandom is presumed to mean
"unlimited". It is a PRNG, though constantly seeded by real entropy,
it may re-use entropy from /dev/random's pool.

The intention for the RandomString resource is for generating passwords
and shared secrets between servers.

So, I think we should document that this is not suitable for long term
encryption keys, and any such need should be satisfied in-instance where
nova-compute can manage access to /dev/random entropy via the hypervisor.

-- 
You received this bug notification because you are a member of OpenStack
Security Group, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1267912

Title:
  OS::Heat::RandomString uses OS entropy source directly

Status in Orchestration API (Heat):
  Confirmed

Bug description:
  The RandomString resource documentation[1] suggests that it's useful
  for generating passwords and secrets. It doesn't mention the security
  guarantees, however.

  Heat seem to be using random.SystemRandom[2]. I'd like us to switch to
  something like PyCrypto or better yet, have Oslo provide a
  cryptographically secure random generator and use that.

  On Linux, random.SystemRandom reads from /dev/urandom which if I
  understand things correctly, can have its entropy depleted. So a Heat
  user could use a template that asks for a huge amount of randomness
  and empty the entropy pool of the entire system (not just Heat).

  This would probably be difficult to exploit, but I think it'd be safer
  use the entropy to seed a CSPRNG instead of using it directly. Which
  is exactly what PyCrypto seems to do.

  Regardless, the security guarantees and implications of
  OS::Heat::RandomString should be documented.

  [1]: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::RandomString
  [2]: https://github.com/openstack/heat/blob/master/heat/engine/resources/random_string.py#L81

To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1267912/+subscriptions