Open Stack

FWIW Tomas I can see how you may have thought that.

This is from the manpage of urandom:

A  read  from the /dev/urandom device will not block waiting for more entropy.  As a result, if there is not
sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic 
attack on the algorithms used by the driver.  Knowledge of how to do this is not available in the current 
unclassified literature, but  it is theoretically possible that such an attack may exist.  If this is a concern in
your application, use /dev/random instead.


(off topic) 
I would like to see a more consistent usage of cryptographic operations across the board. I guess this is the intention of Oslo. If the usage of PyCryto is not advised at this point in time would it make more sense to use something like PyOpenSSL in Oslo instead?  It looks like it is a backend for Jarret's cryptography module so would be a suitable as a temporary dependency or would that just introduce too much busy work?   

So my question is now - Should we raise a bug against the use of
PyCrypto is it hasn't been audited ?

-- 
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