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?
$\begingroup$
$\endgroup$
5
-
2$\begingroup$ HMAC requires 2 keys. GHASH is faster than HMAC with proper cpu instructions $\endgroup$– Richie FrameMar 1, 2014 at 4:21
-
3$\begingroup$ 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). $\endgroup$– user4982Mar 1, 2014 at 20:27
-
$\begingroup$ 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? $\endgroup$– SameeMar 2, 2014 at 20:23
-
1$\begingroup$ @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 $\endgroup$– SameeMar 2, 2014 at 20:27
-
2$\begingroup$ 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). $\endgroup$– Richie FrameMar 3, 2014 at 8:47
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
7
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-then-encrypt or MAC-and-encrypt, using single key).
Cipher-text length is the same for same security level. However CTR+HMAC usually has a longer tag, because hash functions have bigger output than block ciphers, but you can truncate tags to the same length.
If implemented correctly and the block cipher / hash function is secure, both are secure. However, because CTR+HMAC has 2 keys compromising one part won't compromise the other part.
-
2$\begingroup$ 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? $\endgroup$– SameeMar 2, 2014 at 20:32
-
$\begingroup$ Yes, CTR can be processed in parallel, but most hash functions can't process in parallel. While GCM is fully parallel. $\endgroup$– LightBitMar 2, 2014 at 20:52
-
3$\begingroup$ 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. $\endgroup$ Mar 4, 2014 at 20:26
-
$\begingroup$ Polynomial evaluation can be computed in parallel. $\endgroup$– K.G.Mar 4, 2014 at 22:39
-
2$\begingroup$ 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. $\endgroup$ Aug 20, 2014 at 12:38