7

There are several well-regarded block cipher modes for authenticated encryption which have made their way into standards and protocols: CCM, EAX, GCM, OCB, …

If I am designing a new messaging or storage protocol which requires both confidentiality and authenticity of the data, how do I choose between these modes? I am specifically interested in the case of whole-message encryption and integrity verification (as opposed to block storage).

I'm after answers like “pick whichever of X or Y is easily available in your programming environment”, or “padding for this mode is delicate to implement, but it is more robust to a broken RNG”.

(This is in the spirit of AES CBC mode or AES CTR mode recommended? for modes that provide confidentiality only.)

2 Answers2

6

GCM

Personally, I would go for GCM (Galois Counter Mode) since it is efficient – meaning: it handles pretty much everything you’ld expect from it, while other modes sometimes tend to lack a specific feature here and there (see image below for a comparison that shows what I’m hinting at). Also, GCM has a pretty good performance (assuming non-flawed implementation). As you most probably already know, it provides Galois mode of authentication with the well-known CTR mode encryption. The CTR aspect practically means that it doesn’t need any padding (which avoids related attack potential) and it means that you keep a bit of flexibility when it comes to message/package lengths (something CCM for example doesn’t offer, since it uses a fixed block length). Also, the Galois field multiplication used for authentication can be computed in parallel, which enables higher speed/throughput than those authentication algorithms that use chaining modes (like CBC etc). Btw: in case you decide to check on GCM, you might find it handy to know that NIST Special Publication 800-38D includes recommendations for IV selection etc.

The rest…

An alternative at the top of my list would have been EAX mode, which also provides several desirable attributes. But: EAX is a “two-pass scheme”… making it slower than well designed one-pass schemes that are based on the same primitives. Since your designing a messaging/storage protocol, you probably will want to get your hands on all the speed you can get. Two-pass seems not to be an option in that case, pushing EAX down on the list.

Now, you also mentioned CCM. That mode is only defined for block ciphers with a block length of 128 bits, which might be a bit restrictive in size for messaging et al. Which is why I would like to remind you of GCM’s counter mode again…

Last on the list of things you’ve mentioned is OCB. I’m a bit uncomfortable when thinking about OCB, because Ferguson found collision attacks on OCB. The attack limits the data that can safely be encrypted with OCB to around and about 64GB per key. That’s about the same 64 GB limit that GCM has (GCM limits plaintext size to $2^{39} − 256$ bits for any given key and IV combination), but we have to remember that GCM’s limit is “by design”… in the case of OCB, it’s “the result of a collision attack”. From a security perspective, I would therefore tend to avoid OCB. We all know attacks can only get better.

There are a few other things that might or might not make a bit of sense, depending on the individual setting… but in the end, I personally would advise to use GCM for a messaging and storage protocol.


Comparing some of the options…

To compare, you might also want to check out the nice comparison table on slide 7 of this PPT file by David Wagner. I’ll quote it as a graphic here for reading convenience (as you’ll notice GCM is a winner):

comparison table


EDIT

Sometimes, my brain seems to be a bit slow when it comes to remembering papers I’ve once been reading.

Anyway, I’m pretty confident you’ll enjoy reading “Basic comparison of Modes for Authenticated-Encryption (IAPM, XCBC, OCB, CCM, EAX, CWC, GCM, PCFB, CS)” (PDF) which compares a truckload of modes in terms of attributes, speed, implementation, memory usage, tables showing things like the number of the underlying block cipher invocations for each mode, etc.

After reading that, you’ll have ample info at hand to decide for yourself what makes most sense.

Mike Edward Moras
  • 18,161
  • 12
  • 87
  • 240
5

I would pick EAX as it is by far the simplest to implement and therefore to understand and audit. It is reasonably fast if based on AES.

GCM seems quite popular, but I personally see a number of issues with it:

  • it is very difficult to implement in software (which is not surprising, since it was developed with hardware in mind).
  • it is slower than it seems (because of the Galois multiplication) both in terms of throughput and key agility, unless you make use of the PCLMULQDQ instruction available on the most recent Intel CPUs or the VMULL instruction on high-end ARM CPUs (with older CPUs or other architectures you are out of luck though).
  • it is very sensitive to cache-based side-channels attacks because of the large tables one has to employ in order to speed it up to a reasonable level. Again, using the low-level instruction mentioned above solves this problem.
  • using the PCLMULQDQ instruction is not straightforward and it was attacked at least once

In other words, GCM can be fast, secure against side-channel attacks or independent of the CPU architecture. Pick two. Or, as As Adam Langley puts it "GCM is fundamentally unsuitable for software implementation".

Special mention should go to SIV. It is a cute mode based on AES and primarily meant for key wrapping (or Deterministic Authenticated Encryption). Unlike EAX, GCM and most AEAD modes it does not fail catastrophically if the nonce or the counter happen to be reused. That is easy to ensure only in theory: in practice, bad RNGs or virtualized environment may make it very hard. The drawback of SIV is that it is not an online mode (you must see the whole message before starting the encryption) and it requires two independent AES keys.