Is GCM still recommended?

Question

I stumbled across a forum thread where security researcher Thomas Ptacek seemed to have negative feelings towards GCM. I had always thought from prior readings that GCM was the current gold standard for efficient, secure, easy-to-use AES modes?

Here is a summary of the “news.ycombinator” thread:

tptacek: But CTR+HMAC is, in fact, a composed authenticated encryption mode. If you have a working system with CTR+HMAC, I'd recommend against spending effort switching to GCM, which is actually harder to get right.

sargun: I thought AES-GCM was on its way out? Isn't poly1305-chacha20 what we should use now, given that it's quite a bit cheaper in terms of cost, and the keys are much smaller (32 bytes)? Also, the code for chacha is easily available.

tptacek: I definitely personally prefer ChaCha/Poly to GCM, but GCM is unfortunately quite popular right now; of the unencumbered AEADs blessed by NIST, it's very performant and thus widely implemented.

I get that if you have a working crypto scheme like CTR+HMAC working, it isn't worth the effort to switch. What confused me is that he said GCM "is actually harder to get right." What would make GCM mode harder than CTR+HMAC?

Answer 1

The "hard part" about GCM implementation is resistance to side-channel attacks, especially cached-based. GCM is the combination of AES-CTR, and a custom MAC that relies on multiplications in a binary field (GF(2¹²⁸)). Efficient implementation of that operation classically uses tables, which can lead to cache-timing attacks because the accessed table slots will depend on the secret data (though cache-timing attacks have never, to my knowledge, been spotted "in the wild", they work very well in lab conditions so the common wisdom is that they are a plausible threat).

If you have a recent enough x86 CPU then you have the AES-NI opcodes, which help for AES but also for multiplications in binary fields, making GCM both resistant to side-channel leaks and very efficient. But smaller devices do not necessarily have the luxury of such a hardware-assisted implementation. In fact, it may be argued that performance is much more likely to be an issue on small embedded CPU (say, the low-end 32-bit ARM CPU) than on big PC, where encryption only uses a small fraction of the available computing power.

For small CPU, Poly1305/Chacha20 will be faster, with a smaller footprint, and more resistance to side-channel attacks. Techniques for making a constant-time implementation of AES are still applicable (like the Kasper-Schwabe implementation) but will offer lower performance because a 32-bit small CPU has only 32-bit registers (the Kasper-Schwabe code uses bitslicing techniques to run 8 parallel AES instances over 128-bit registers, but with 32-bit registers this goes down to 2 parallel AES instances). For the binary field part, one can use plain integer multiplications, but with most bits cleared to avoid problems with carries, so there will be a lot more multiplications than with a prime-field based MAC like Poly1305.

GCM is there to stay because it got NIST blessing and thus made its way to many standards; it even convinced CPU vendors to include specialized opcodes, and this in turn will reinforce its position.

Meanwhile, research on AEAD modes is still active, and there is an ongoing competition with interesting candidates (e.g. NORX). Thus, while there is a bit of dissatisfaction over GCM because of implementation issues, the succession is still open. Poly1305+ChaCha20 got a little headstart by being there first, but that does not make it an automatic fallback.

A common problem to both GCM and Poly1305+ChaCha20 is the need for a non-repeating IV. Such an IV is easily managed in the context of a streamed protocol (such as SSL/TLS) but it can be a source of trouble for encryption of independent messages -- IV reuse is a mortal sin and is not easily tested for in a given implementation. An IV-less encryption system would need to be a two-pass method (which is not necessarily a problem for encrypting messages); a possible candidate would be a counter-intuitive MAC-then-encrypt construction, with (say) HMAC computed over the plaintext, and the HMAC value being used as IV for AES-CTR encryption.

Answer 2

There are different arguments going on and there is some context guessing involved on part.

• The argument to stay using CTR+HMAC seems to be, basically:

  Never change a running system (without the need to).

  The security of CTR+HMAC is fine per se. If you have a good, working implementation and the computatational complexity is not biting you, you should rather leave it as-is.

• The use of GCM and ChaCha/Poly

  I definitely personally prefer ChaCha/Poly to GCM, but GCM is unfortunately quite popular right now; of the unencumbered AEADs blessed by NIST, it's very performant and thus widely implemented.

  If you are to use NIST-approved ciphers, AES-GCM is the easiest to deploy, giving good performance. ChaCha/Poly is not yet NIST-blessed, so may cannot be used in certain szenarios.

• The preference for ChaCha/Poly

  This is rather a personal preference, as the quote states, too. There are many reasons to prefer either. And especially good reasons (no hardened library available for some languages) to prefer AES-GCM.

• Additional notes

  They might be talking about ease of implementation in terms of crypto libraries. As you are not to roll your own, this may not be of any interest for developers just using crypto libraries.

  For cipher developers (which are rolling their "own"), ciphers with simpler algorithms are of course easier to get right, not making fatal mistakes implementing them. That is a good reason to choose the cipher with less implementation tidbits.

  If they are in fact talking about ease-of-use rather than ease-of-implementation, I'm not following their argument and might need more context.