Return to Answer

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.

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.

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.

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.

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

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.