18

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?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Samee
  • 281
  • 1
  • 2
  • 3
  • 2
    HMAC requires 2 keys. GHASH is faster than HMAC with proper cpu instructions – Richie Frame Mar 01 '14 at 04:21
  • 3
    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 01 '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 02 '14 at 20:23
  • 1
    @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 02 '14 at 20:27
  • 2
    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 03 '14 at 08:47

1 Answers1

13

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.

artxur
  • 103
  • 2
LightBit
  • 1,649
  • 13
  • 27
  • 2
    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 02 '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 02 '14 at 20:52
  • 3
    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 04 '14 at 20:26
  • Polynomial evaluation can be computed in parallel. – K.G. Mar 04 '14 at 22:39
  • 2
    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
  • @rmalayter SHA-3 is faster than SHA-256 only, if implemented in hardware. SHA-3 can't be computed in parallel (Keccak function is however more parallel than SHA-256 compression function, but sponge construction is inherently sequential). Why not use Keccak in SpongeWrap mode to encrypt and mac in single pass than? It is simpler and faster, but still not parallel. – LightBit Sep 02 '15 at 19:39
  • @LightBit I agree. SHA-3 is only inherently parallelizable when used in "tree hashing" mode which is specified by Keccak authors but not standardized as far as I know. I don't think NIST standardized an AEAD mode yet either. Really though any MAC can be computed in parallel on a separate thread from encryption if passed the cipher text blocks as soon as they are ready (shared memory or whatever mechanism). – rmalayter Sep 03 '15 at 21:24