[CHEF-5356] Encrypted data bags should use different HMAC key and include the IV in the HMAC

https://tickets.opscode.com/browse/CHEF-5356
> Is this a standard format for the key? If so, it would be great to refer to it by name or link.

I simply divided the string in half. Usually this is implemented using a hash function and splitting the result of it to obtain two keys. Something like the following:

```pseudocode
keys = hash(secret) # >= 160 bytes output
hmac_key, data_key = keys.split
```

But we need a key length of 32+128 = 160 bytes, and I have not found a hash function in Ruby to generate a key of this length. So, instead of splitting the hash and obtain two keys, I have split the initial secret by half and used two hash functions to obtain two keys.

OK, my explanation is really confusing. I show you how it works in pseudocode:

```ruby
hmac_secret, data_secret = secret.split # split the string in half
data_key = sha256(data_secret) # 32 bytes output
hmac_key = sha512(hmac_secret) # 64 bytes output
```

Then the data is encrypted using the following procedure:

```ruby
encrypted_data = encrypt_aes_256_cbc(iv, data_key, data) # 32 bytes input key length
hmac = hmac_sha256(hmac_key, data_to_hmac) # 64 bytes block length
```

> Also, do we have documentation suggesting a recommended way to generate the encryption keys?

There is a way to generate multiple keys from a secret known as Key Derivation Function or KDF:

* http://en.wikipedia.org/wiki/Key_derivation_function
* http://www.di-mgt.com.au/cryptoKDFs.html
* http://en.wikipedia.org/wiki/PBKDF2

Using those functions, you provide a secret and it generates multiple keys.

But considering that the secrets of the data bags are generated automatically and not typed by hand, I considered duplicating its size is not such a great effort and will always be more secure than using a key generator.

Another way is to generate the keys using `OpenSSL::Cipher#random_key` or randomly, but as we are using a user provided secret as input, that becomes more complicated. So I discarded that idea.

> This halves the effective entropy we're using for the key, which means we should recommend to create keys 2x the size, right?

Yes, you are rigth. But keep in mind that this two secrets are not used directly, they are hashed and the hash result is then used as key.

Anyway, do you prefer me to change my approach for any of these ideas?