Open Stack

Should my opinion on what has to happen in Oslo go here?

I think the resolution for *this* ticket is that Heat should use
https://github.com/openstack/oslo-
incubator/blob/master/openstack/common/crypto/utils.py#L99. Then, we
make *that* good.

So, my opinions on that, which I think should also be in a different
ticket:

Crypto issues:

- The crypto primitive should probably be NaCl/libsodium's crypto_secretbox(_open). That's Salsa20 with a Poly1305-AES authenticator, but you shouldn't care too much about that :)
- os.urandom should be used exclusively as a CSPRNG. User-level CPRNGs can certainly be done right, but there's plenty of ways to get them wrong. (Say, PyCrypto2.6.0, sometimes, when forking. And I don't even want to remember what I have to do to use RAND_bytes(3) properly in all cases). Since you eventually always rely on /dev/(u)random to get your seed anyway, I don't see the point. FWIW, cperciva disagrees with me, and he's smarter than me; but tptacek agrees with me, and he's smarter than me too. cperciva's arguments *might* be valid in Heat, since he's suggesting same-host entropy use leaks. I'm not convinced those are real attacks. I am convinced that your CSPRNG being broken leads to real attacks ;)
- The padding routine in Oslo isn't constant time. This leaks information about the ciphertext length mod block size. In a system emitting a limited number of messages with predictable sizes, that's pretty bad.
- The unpadding routine in Oslo blindly unpads the ordinal value of the last byte worth of bytes from the plaintext. That's a lot of options for generating valid (parseable) truncated messages.

This is not an exhaustive list. All of the above issues would be fixed
by leaving crypto up to NaCl/libsodium, except for key generation (which
possibly isn't broken in the first place).

API issues:

- For a symmetric key API, there should not be separate "authenticate" and "encrypt" methods. There should be *only* encrypt, and that should /mean/ encrypt-and-then-MAC-the-ciphertext (EtM). Alternatively, you can also call it "encrypt_and_authenticate" :) The existence of *just* "authenticate" for authenticated plaintext messages is fine. There is no reason to expose the unauthenticated encryption foot-gun. Also, having them be separate methods means that people can get it wrong, for example, they could MtE (first MAC, append MAC to plaintext, then encrypt both), or they could E&M (encrypt plaintext, MAC plaintext, concatenate both). All of these are footguns. The public API should not let you get it wrong.
- The verb "sign" should be reserved for public key signatures.

These two groups of issues are orthogonal.

cheers
lvh

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

Title:
  Heat does home-grown symmetric crypto (AES-CFB) for no apparent reason

Status in Orchestration API (Heat):
  Triaged
Status in OpenStack Security Advisories:
  Invalid

Bug description:
  In the following commit:

  https://github.com/openstack/heat/commit/58cd52624b50476ed5ed1c5c0ba7cb1b4d7ba66d

  ... a decision was introduced to encrypt authentication information
  using unauthenticated AES-CFB.

  There's a few things I don't like about that commit, but suffice to
  say that  heat/engine/auth.py should probably not be a place where
  symmetric crypto decisions are made.

  I've been told that there's a new public API for symmetric encryption,
  SymmetricCrypto that lives in  openstack/common/crypto/utils.py:
  https://github.com/openstack/oslo-
  incubator/blob/master/openstack/common/crypto/utils.py#L99

  I think that also gets a few things wrong, but at the very least Heat
  should use a centralized thing for encrypting stuff.

  (I'd love to complain about and work on SymmetricCrypto too, but
  that's not this ticket :)

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