# Why does AES-GCM not require an auth key, but encrypt-then-mac does?

The inputs to AES GCM mode appear to be:

• an IV
• a key
• message to encrypt

The output is a cipher and auth tag.

However, if one were to manually perform an encrypt-then-mac scheme, the inputs required would be:

• an IV
• a key
• an auth_hash (for decryption)
• an auth_key
• message

Then, you would compare auth_hash == HMAC(message, auth_key) before decrypting(message, key, IV).

So with the manual approach, there are 2 more inputs. Why is GCM able to do the same thing with less inputs?

AES-GCM does require an authentication key. You don't need to pass it because it is generated from the encryption key by encrypting an all-zero "plaintext" block:

The hash subkey, denoted $H$, is generated by applying the block cipher to the “zero” block. The resulting instance of this hash function, denoted $GHASH_H$, is used to compress an encoding of the AAD and the ciphertext into a single block, which is then encrypted to produce the authentication tag.

(source - in "5.3 Primitives for Confidentiality and Authentication")

• Would I be able to do something similar with an encrypt-then-mac scheme to avoid having to have a unique encryption key and an auth key? Mar 8 '17 at 0:30
• Probably, but I don't know the requirements that make it secure in the case of AES-GCM.
– knbk
Mar 8 '17 at 0:32
• @Snowman Typically one uses a key derivation function applied to one root key to derive different keys for encryption and authentication.
– Mark
Mar 8 '17 at 17:32
• If the attacker gets the encryption key, then it could decrypt the cipher text and authenticate tag? Does the client and server computes the authentication key individually? Does the authentication key needed to be exchanged in the handshake? Oct 25 '17 at 13:08
• @kingluo The authentication tag is sent along with the ciphertext. If an attacker has the encryption key, they'll be able to forge an authentication tag for any message.
– knbk
Oct 25 '17 at 13:23

I don't get auth_hash, I presume that this is either a configuration option for the hash algorithm to use or an output instead of an input. As you already split the ciphertext and the authentication tag, that leaves us with the additional key.

GCM has been specifically designed as an AEAD cipher. So it makes sense that the construction only uses a single key.

With encrypt-then-mac the cipher and MAC algorithm are separate algorithms. Basically it is not proven that using the same key for both the cipher and the MAC doesn't introduce weaknesses. It is even known that using CBC mode encryption and CBC-MAC is dangerous (although the key would still be protected by the cipher).

That said, it is pretty unlikely that encrypt-then-HMAC is vulnerable to attacks. HMAC is a strong algorithm and the hash is pretty far apart from the usual cipher implementation. So it is rather unlikely that using the same key for both introduces issues. It is however best practice to use two different keys for two different purposes, if just to help with security proofs.

• I'll be voted into the ground by CodesInChaos if I didn't get this right ;) Mar 8 '17 at 0:20
• The auth_hash is an input to the decryption method outputted from a previous HMAC. Mar 8 '17 at 0:22
• Either you should add this to the GCM inputs (possibly as part of the AAD) or you should remove it from the inputs of encrypt-then-mac. Otherwise they aren't functionally equivalent. Mar 8 '17 at 0:25
• Well it's not an input. I was just saying that when manually performing an HMAC, the result is the auth_hash (or tag). Then when you go to decrypt, you need to generate a local authentication hash to compare with the remote auth_hash. No? Mar 8 '17 at 0:33
• That's the same with the authentication tag of GCM though, so it isn't a difference. Mar 8 '17 at 0:35