Open Stack

As far as I know, the C backend for PyCrypto has not been audited. There
really isn¹t a supported Python library suitable for crypto use (if you
want something audited, obviously PyCrypto is widely deployed).

My team is working with a bunch of other folks to remedy this situation.
We are unifying a lot of the python libs and pretty much all of them are
onboard. It¹s too new to move oslo.crypto onto it, but that is my plan for
later this year. 

We just had our first release that is being used as the new backed for
pyopenssl, but there is lots of work left to do. I¹ve CC¹d Paul Kehrer who
is one of the Barbican devs working on the project.

The code is here if anyone is interested:
https://github.com/pyca/cryptography


Jarret


On 1/13/14, 12:30 PM, "Tomas Sedovic" <tomas at sedovic.cz> wrote:

>Jarret and Clint, thanks for the clarification, I completely
>misunderstood urandom.
>
>In that case, it makes sense to keep using SystemRandom. On a tangential
>note, I assumed PyCrypto has been audited since it's powering
>oslo.crypto. Has that not been the case?
>
>Anyway, I agree with Clint's suggestion regarding the documentation.
>
>-- 
>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
>
>_______________________________________________
>Openstack-security mailing list
>Openstack-security at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security

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