# Key size, performance, and security tradeoffs for AES-GCM, CCM

AES can be used with 128, 192 or 256 bit keys and each one appears to have a performance vs security trade-off (What is the effect of the different AES key lengths?, What are the practical differences between 256-bit, 192-bit, and 128-bit AES encryption? and other answers). It appears that from a practical standpoint, 128 bit keys are sufficient for using AES encryption alone.

However, it seems like this equation changes when we use AES-GCM/CCM. My understanding is that the same performance effects of using larger keys do apply for AES-GCM and AES-CCM, but the security strengths of brute forcing the key are different ($$n \over 2$$, https://tools.ietf.org/html/rfc3610) due to pre-computation attacks enabled by reuse of nonce/IV for different keys. There appear to be suggestions in the RFC where the nonce/IV for these modes include a salt(random) and a counter to provide a slight increase in security against pre-computation attacks.

Does this not reduce the number of blocks and max data size that can be encrypted under the same key? The amount of encrypted data reduces for a randomly constructed nonce with AES-GCM; why would this reasoning not apply for CCM?

In summary my questions are:

1. What are the main reasons why 256 bit keys are recommended for AES-GCM and CCM instead of 128 bits, and why is AES128 bit sufficient for encryption otherwise?

2. Will there be significant gain in performance using 128 bit vs 256 bit keys with AES-GCM / CCM or do non-AES part of AES-GCM / CCM dominate performance or execution time?

3. Do the restrictions on message size and total amount of data authenticated under the same key change with TLS like nonce construction (32 bits random, rest of it a counter)?

4. Is ChaCha20-Poly1305 vulnerable to this pre-computation attacks?

ChaCha20-Poly1305 seems to provides 256 bit strength for encryption and a little more than 100 bits of security for authentication and the only condition seems to be related to the nonce just like the rest.

• Note that in GCM mode there are two keys, one for producing the ciphertext and one for producing the tag. It may help to clarify which key you are talking about when discussing their security bounds. – puzzlepalace Feb 11 at 22:04
• From a user point of view, there is only one key for AES-GCM. I'm talking about that one input key. – Raghu Feb 11 at 22:07
• Note also that the reduction in security mentioned in the RFC you cite is under very specific conditions, namely that the attacker is able to observe $2^{64}$ messages that all start with the same plaintext block, encrypted under the same key, and that this plaintext block is known to the attacker. – puzzlepalace Feb 11 at 22:21
• I tried answering the question and got stuck on #3, for which I have to research a bit to be sure of my answer. I suppose this is the danger of asking so many questions at once. – Maarten Bodewes Feb 13 at 0:55
• Not necessary that you need to answer all the questions :) Any information is valuable and might just be enough to get me to the answers. Not sure if your comment is criticism. If it is criticism It would be great if you can tell me how I can make the question better. Perhaps split it into different questions on the forum ? Or ask follow up questions to answers ? – Raghu Feb 13 at 17:21