3

We determine a system IND-CPA secure when an adversary has a negligible advantage after any feasible amount of queries.

AES256-GCM uses a 128bit block cipher.

We know that the distinguishability from random of counter mode encryption follows the birthday bound.

If we encrypt a stream of static data, with counter mode encryption we will never see a repeated cipher text block.

A purely random oracle will have repeats. The probability of this happening follows the birthday bound, eg after $2^{64}$ blocks we expect a repeat with probability of about a half. This would give an attacker an advantage of one half with $2^{64}$ queries, which is completely insecure.

If we assume a negligible advantage of $10^{-9}$, we reach that after about $2^{54}$ blocks. This means we should limit the maximum amount of blocks encrypted under a single key to $2^{54}$ blocks right?

This is way less than the advertised $2^{32}$ invocations of $2^{32}$ block chunks in NIST SP 800-38D.

Why don’t we see any recommendations of limiting the use of AES256-GCM dependent on its security parameter due to this attack on the counter mode encryption?

1 Answers1

2

You are right that it is generally foolish to try to use AES-GCM for zetabytes of data under a single key. The standard ought to have clearer data volume limits.

For a long time, the folklore understanding was that a non-collision in a CTR stream doesn't really leak all that much…until sweet32 demonstrated that it actually can be a real problem. Still, what is feasible for a 64-bit cipher with online cost ${\sim}2^{32}$ may be considerably harder for a 128-bit cipher with online cost ${\sim}2^{64}$.

An alternative is to use crypto_secretbox_xsalsa20poly1305, which is a pseudorandom function family rather than a pseudorandom permutation family like AES, so the generic birthday distinguisher for permutation-based CTR doesn't apply. One could also imagine using a wider-block cipher like Threefish-256, in which case the birthday bound is unimaginably larger; it is a pity that AES was standardized with a meager 128-bit block.

Squeamish Ossifrage
  • 49,816
  • 3
  • 122
  • 230