3
$\begingroup$

I would like to let the receiver has the ability to check the sender's authenticity when he gets the message.

Also, I want to protect the message's confidentiality and integrity.

Should I use aes gcm + hmamc or just aes gcm?

I heard aes gcm provides messages authentication suing Ghash. But ghash is not a mac, so I am confused how aes gcm achieve message authentication

$\endgroup$
3
  • $\begingroup$ GHASH is a MAC. Specifically it computes an authentication tag (AKA:MAC) for a given ciphertext.. The Wikipedia articles on both should have made this very clear. $\endgroup$ Jun 17 at 13:41
  • 3
    $\begingroup$ @RichardThiessen: no, GHASH is not a MAC - given the values $A, C, GHASH(H, A, C)$, it is easy to recover the secret key $H$ (or, at least, list a handful of values it might be). What is a MAC is $AES(Nonce || 0 ) \oplus GHASH(H, A, C)$ $\endgroup$
    – poncho
    Jun 17 at 13:46
  • $\begingroup$ Point, yes, GHASH by itself is not a MAC. $\endgroup$ Jun 17 at 13:52

1 Answer 1

3
$\begingroup$

Should I use aes gcm + hmamc or just aes gcm?

Just aes gcm is fine - GCM includes the integrity protection.

I heard aes gcm provides messages authentication suing Ghash. But ghash is not a mac, so I am confused how aes gcm achieve message authentication

Ghash is indeed not a MAC - it is a universal hash. However, because the output of ghash is xor'ed from the output of AES (based on the nonce), that is indeed a MAC (a Carter Wegman MAC), and so provides the integrity protection you are looking for. That is, if the adversary makes any modification to the ciphertext, then (assuming AES is strong and the sender never encrypts two different messages with the same nonce) the modification will be detected with provably high probability.

Note: there are details I glossed over - not every universal hash xor'ed with per-packet secret data is a secure MAC. If you want to dig deeper into the theory behind GCM (and Poly1305, which works similarly), submit another question.

$\endgroup$
6
  • $\begingroup$ Thanks. My question is if gcm also provides the authentication that hmac provided? $\endgroup$ Jun 17 at 13:49
  • $\begingroup$ will the aes gcm allow the receiver to check the sender's identity? $\endgroup$ Jun 17 at 13:51
  • 1
    $\begingroup$ I would argue this is misleading. AES-GCM is not committing, whereas Encrypt-then-MAC done correctly is fully committing. So is AES-GCM-then-HMAC, but that's needlessly inefficient. Whether no commitment leads to a vulnerability or not depends on the protocol, but it should be fixed in future AEAD schemes. AEGIS and Rocca-S are committing with a 256-bit tag. $\endgroup$ Jun 17 at 20:26
  • 1
    $\begingroup$ @samuel-lucas6, being committing is a nice additional feature that would be reasonable to add in an answer to the question. But I don't think it is fair to say this answer is misleading. The question was quite specific on the MAC aspect of GCM; key/context commitment attacks do not invalidate the int-ctxt security of GCM, which is more the spirit of the question IMO. Also, the OP has not clarified whether the target application would need additional robustness guarantees. Another answer that highlights the need for key/context commitment is naturally a great addition. $\endgroup$ Jun 19 at 16:36
  • 1
    $\begingroup$ @MarcIlunga I agree; I was referring to the comment above mine but wasn't clear. However, I do think commitment is important to mention as it technically is the answer to the title of the question - HMAC provides commitment, whereas AES-GCM does not. I will try to write an answer at some point if I'm feeling up to it. I like how quick comments are. $\endgroup$ Jun 19 at 17:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.