23
$\begingroup$

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?

$\endgroup$
  • 1
    $\begingroup$ You are missing an important fact: recommended what for? What is to be achieved in terms of security, implementation ease, runtime complexity,... $\endgroup$ – Tobi Nary Apr 11 '16 at 14:54
  • $\begingroup$ @SmokeDispenser Sure. Take a typical SaaS application that wants to encrypt some user data in some storage medium on a server. Should run as quickly as possible, but at the end of the day they can afford some cycles since it isn't on an embedded device. Implementation ease is crucial since most backend developers are not going to be crypto experts. Probably not trying to secure against state level adversaries, but if it does then all the better. $\endgroup$ – Anthony Kraft Apr 11 '16 at 15:09
16
$\begingroup$

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(2128)). 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.

$\endgroup$
  • 1
    $\begingroup$ is there any reason a properly generated random 128 bit value wouldn't solve the non-repeating IV problem? Other than being slower than other methods? $\endgroup$ – Anthony Kraft Apr 11 '16 at 15:34
  • 2
    $\begingroup$ A main reason is that proper generation of random values is one of the hardest problems when implementing crypto on embedded devices -- in particular because the quality of the randomness cannot be really tested. $\endgroup$ – Thomas Pornin Apr 11 '16 at 15:37
  • $\begingroup$ @AnthonyKraft Another approach to mitigating repeating IV issues is a nonce-misuse-resistant construction. For AES-GCM, this comes in the form of AES-GCM-SIV. $\endgroup$ – Xander Apr 11 '16 at 16:00
  • 1
    $\begingroup$ Note that you're strongly adviced to use a 96 bit nonce / IV for GCM. There are some issues with using a differently sized nonces, and the specs even recommend implementations to support 96 bits (12 bytes) only. This of course posted in relation to the first comment below this answer, mentioning a 128 bit value instead of a 96 bit value. $\endgroup$ – Maarten - reinstate Monica Oct 30 '16 at 16:51
4
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ I also assumed the GCM complexity was one of library author vs user of library. There is, unfortunately, no further context to the discussion so we'd have to ask the author himself for clarification unless someone else can present some fatal issue relevant to GCM usage over CTR+HMAC. $\endgroup$ – Anthony Kraft Apr 11 '16 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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