Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I stumbled across a forum thread where a security researcher 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 forum 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?

*tptacek is security researcher Thomas Ptacek

*original source: https://news.ycombinator.com/item?id=11468324

share|improve this question

migrated from security.stackexchange.com Apr 11 at 18:23

This question came from our site for information security professionals.

1  
You are missing an important fact: recommended what for? What is to be achieved in terms of security, implementation ease, runtime complexity,... – SmokeDispenser Apr 11 at 14:54
    
@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. – Anthony Kraft Apr 11 at 15:09
up vote 8 down vote accepted

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.

share|improve this answer
    
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? – Anthony Kraft Apr 11 at 15:34
    
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. – Thomas Pornin Apr 11 at 15:37
    
@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. – Xander Apr 11 at 16:00

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.

share|improve this answer
    
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. – Anthony Kraft Apr 11 at 15:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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