1
$\begingroup$

It is recommended to use different keys for different purposes, such as encryption and integrity protection. As I see it, AES-GCM only requires one key as input. Two different keys are then generated from the provided key, basically meaning that one key is used for two different purposes! Should one, not, consider using the traditional encrypt then HMAC instead? This would ensure that, under the assumption that the implementation does not simply use a single key, unrelated keys are used for different purposes.

My question is, therefore, why is AES-GCM so widely accepted? In what circumstances should one consider using EAS-GCM instead of the traditional encrypt then HMAC?

$\endgroup$

migrated from stackoverflow.com Oct 30 '18 at 11:10

This question came from our site for professional and enthusiast programmers.

2
$\begingroup$

TL;DR: GCM has been shown to be secure, which is not the case for encrypt-then-HMAC.


There are a few things to distinguish here. First is the difference between asymmetric and symmetric cryptography. If messages are encrypted with the public key of the recipient and signed with the private key of the sender then there is a clear difference in key usage. Obviously the private keys when sending messages are kept by different parties. Now these parties could use the same key for decrypting and signing, but these keys may well have different life times. For instance, it may be that you want to decrypt messages in the far future, meaning that you need to keep the private decryption key. However, generally you don't need to keep the signing key; you can still verify messages with just the public key and replace the signing key with the new key.

However, with an authenticated cipher such as GCM we're commonly dealing with session keys. The session keys for confidentiality and integrity protection / message authentication are commonly generated at the same time. So there is no need to have separate life times or access conditions for them.


Another reason to use separate keys are algorithmic vulnerabilities. Cryptographic algorithms will always be designed to keep the key secure. However, the algorithmic proofs (or at least indications of security) generally do not consider usage of the key in other algorithms. Imagine you have a set of equations trying to show security. Now mix those equations with a whole new set of equations from another algorithm that uses the same variables, and try to show that security holds. This is generally impossible, meaning that any security reduction is likely void.

In the worst case the encryption algorithm and MAC use similar constructions. In that case it might well be that the resulting set of equations is actually insecure. A good example of this is a block cipher mode in CBC mode that uses CBC-MAC. It is easy to prove that this scheme can be insecure when used with the same key.

HMAC is a completely different scheme than any block cipher mode of operation. That makes it very improbable that re-using the key for authentication will lead to vulnerabilities. However, it will also be next to impossible to prove that there aren't any, so it is therefore still not recommended to reuse the encryption key for authentication with HMAC.


A slightly less serious issue is that keys may not be usable for different algorithms. For instance, a HMAC-SHA512 (SHA-512 is often faster than SHA-256) key cannot directly be used for AES encryption, as the maximum key size of AES is 256 bits. For software this may not be a huge issue, but generally keys are generated for a specific algorithm. This is especially an issue on hardware modules, where the key data can often not be retrieved. It would be impossible to use a HMAC key as an AES key.

So it may be easier to have one input secret that can be fed into a key derivation mechanism such as HKDF. This mechanism can then be used to derive the encryption and authentication key. This is an easy way to split one secret key into two secret keys. Obviously this option is not available in the setting that requires asymmetric cryptography.


For AES-GCM the key is only used in AES-CTR mode. This mode is both used for protecting the GMAC value (with a specific counter value) as well as keeping the message confidential. This construction is shown to be secure in a paper that is unfortunately payware. This proof has been studied by other cryptographers and shown to be valid. There have certainly have been results that have shown weaknesses in the GCM construction with regard to construction of the authentication tag and derived authentication key, but the overall security claims have withstood the issues - after some tweaking.

So unless further holes in the security claims will be found, AES-GCM should be secure even though it just requires one key.


For the scholar, here is the security claim in the original paper:

GCMis secure in the concrete security models introduced by Bellare, Killian, and Rogaway [20] for message authentication, and Bellare, Desai, Jokipii, and Rogaway for confidentiality [22], against adversaries that can adaptively choose the plaintext, the additional associated data, and the IV (as long as the requirements on these inputs are respected). Its security relies on the fact that the underlying block cipher cannot be distinguished from a random permutation, an assumption which is common in cryptographic designs and which appears to be valid for the AES.

And here is a link to a freely available draft that is likely the source for the linked-to payware paper in the previous section: Flexible and Efficient Message Authentication in Hardware and Software

$\endgroup$
1
$\begingroup$

The guidance of using separate keys for separate purposes originally came due to security vulnerabilities: Vulnerabilities were popping up due to algebraic properties that were causing security problems due to the way that classic algorithms were being implemented at the time. For example, textbook RSA is not very secure for many reasons, one being that if you encrypt and sign with the same modulus, then it is trivial to create existential forgeries.

Times have changed. We have better standards and better foundations for the security of various algorithms. I don't think you're going to run into problems if you use the same RSA modulus for both OAEP encryption and PSS signatures. At least we can prove the security in the random oracle model.

One could still make an argument on why it is good practice to use separate keys for separate purposes, but the justification is not as strong as it was 30 years ago.

Why is AES-GCM so widely accepted? It has been reviewed by the world's best cryptographers. This is not to say that it is perfect: in fact, it is fragile to IV re-use, and new algorithms are being developed to address this shortcoming. Having said that, developers are more likely to get encrypt and MAC constructions wrong. In fact, I just saw such an example a few minutes ago of a person attempting that and getting wrong.

So, the upshot? If you are careful to not re-use an IV, then go with AES-GCM. If you are not careful, then do the encrypt-then-mac construct.

$\endgroup$
0
$\begingroup$

EAS-GCM authentication key is generated from the encryption key by encrypting an all-zero "plaintext" block.

So, the security of the system relies on the encryption key. There is no proof that this is insecure. If you get the encryption key, you can definitely forge messages. So using two separate key only increase the key size and storage to keys.

For example neflix uses AES-GCM. also, BCrypt and HKDF.

Traditional is simple protocole compared to AES-GCM.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy