Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So these days I see everyone using AES-GCM. What are its advantages over simple CTR+HMAC modes? Is it speed? Or ciphertext length? And what are the security tradeoffs, both in terms of practical cryptanalysis and theoretical attacks complexity?

share|improve this question
HMAC requires 2 keys. GHASH is faster than HMAC with proper cpu instructions – Richie Frame Mar 1 '14 at 4:21
One tradeoff: 128 bit authentication tag (maximum of AES-GCM) is sufficient for the most uses. However, if you need longer tag, then you need another MAC, such as HMAC (with suitable hash function). – user4982 Mar 1 '14 at 20:27
Well, 2 keys doesn't seem to be a big problem: we can always derive 2 keys from one key k using PRG_k(1) and PRG_k(2), right? – Samee Mar 2 '14 at 20:23
@RichieFrame: what kind of hardware support are we talking? And lacking hardware support (e.g. embedded devices / phones), which is faster? Any links about this would be appreciated – Samee Mar 2 '14 at 20:27
AESNI + PCLMULQDQ or equivalent CPU instructions, or a hardware path. With enough memory speeds exceeding 3 cycles per byte per core. Haswell server processors will be even faster, pushing 25+GB/s per socket. On standard 64-bit devices, you can expect GCM to be about the same speed as HMAC, although on short messages GCM will be much faster, up to 10X, maybe more. GCM on ARM processors with NEON is reasonably fast. More constrained devices would be better off with OCB mode, as GHASH is very slow (maybe 5X). – Richie Frame Mar 3 '14 at 8:47

AES-GCM uses single block cipher operation and can be processed in parallel, therefore it should be faster.

CTR+HMAC requires block cipher and hash function, which usually can't be processed in parallel. Also it requires 2 keys. It is often miss-implemented (MAC-than-encrypt or MAC-and-encrypt, using single key).

Cipher-text length is the same for same security level. However CTR+HMAC usually has longer tag, because hash functions have bigger output than block cipher. But you can truncate tag to same length.

If implemented correctly and block cipher / hash function are secure, both are secure. However, because CTR+HMAC has 2 keys compromising of one part won't compromise the other part.

share|improve this answer
So I heard that parallelism argument, but that's why I was comparing it to CTR. How is the parallelism in GCM different from that in CTR+HMAC? – Samee Mar 2 '14 at 20:32
Yes, CTR can be processed in parallel, but most hash functions can't process in parallel. While GCM is fully parallel. – LightBit Mar 2 '14 at 20:52
GCM is not fully parallel, it requires the previous ciphertext block to be hashed before it can move on to the next one, and usually does this in groups of 4 or 8. – Richie Frame Mar 4 '14 at 20:26
Polynomial evaluation can be computed in parallel. – K.G. Mar 4 '14 at 22:39
SHA-3 can be computed in parallel, is faster than SHA-256, and doesn't even require HMAC for security (simple message concatenation with key is secure). So AES-CTR with a SHA-3 mac might be the simplest and even fastest option on newer servers. GCM is notoriously complex to implement securely, negating the conceptual simplicity of GHASH. Simpler is always better for security and often performance. – rmalayter Aug 20 '14 at 12:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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