Does using the same secret key for AES-256-CBC and HMAC-SHA512 in Encrypt-then-MAC potentially compromise the key?

Question

Suppose I use a key (and IV) to encrypt a piece of binary data with AES-256-CBC to produce the corresponding encrypted data.

Suppose I then throw this encrypted data into HMAC-SHA512 using the same key as above to produce a MAC. I send the encrypted data and the MAC to a recipient.

The recipient can now verify the encrypted data against the MAC (if he knows the key).

My question is simply: Does the fact that the key I used for AES-256-CBC I also used for the HMAC-SHA512 potentially compromise my key in any way? In other words, is this a potential added attack vector against my key (due to potential weaknesses in SHA-512, or something else)?

To put it differently, I'm just wondering whether there is any difference in terms in protecting a key if that key is used only for AES-256-CBC versus used for both AES-256-CBC and HMAC-SHA512.

Would I be better off using CBC-MAC? (Especially if using CBC-MAC makes the key go through AES-256-CBC as well, adding no additional attack vectors? I'm not sure of this.)

Answer 1

This question is effectively answered by a variation of the question over on crypto.SE, here: Using the same secret key for encryption and authentication in a Encrypt-then-MAC scheme

The pertinent part of the answer is here: (emphasis mine.)

Potential problems with using the same key for encryption and MAC would be structural; [One] example is CBC-MAC, which is indeed identical to CBC encryption, except that you only use the last encrypted block as MAC. CBC-MAC works fine as long as you do not give to the attacker access to pairs (p,c): p is a plaintext block, c is the corresponding ciphertext block, for the key k which you use for CBC-MAC. But if you use the same key k for encrypting the data, then you are giving to the attacker a lot of such blocks.

With HMAC vs AES, no such interference is known. The general feeling of cryptographers is that AES and SHA-1 (or SHA-256) are "sufficiently different" that there should be no practical issue with using the same key for AES and HMAC/SHA-1. However, simply defining that "difference" with any kind of scientific rigor would be hard, and it is not a much explored security feature. So that's one of these constructions which can be qualified as "no urgency to fix it, but don't do it if you can avoid it". A much "safer" way (in the sense of: "we know what characteristics of the involved algorithms we are exercising") is to take your master key K, and derive from it, with a good one-way Key-Derivation Function, a sub-key for encryption and another sub-key for the MAC. This can be as simple as applying SHA-256 on K and splitting the 256-bit result into two 128-bit keys.

There are some MAC and encryption algorithms which intrinsically support sharing the same key. This is exactly what happens in GCM.

So, the general consensus is that the security is ok, and you don't introduce vulnerabilities by sharing a key between AES and HMAC, but it is also general consensus that it isn't good hygiene to reuse a key for different purposes. So what we resolve down to is that this construction is generally frowned upon, but there are no known or suspected security weaknesses at this time.