According to the Wikipedia article on Galois/Counter Mode, GCM is limited to encrypting $2^{39} − 256$ bits of plain text (64 GiB) for any given key and initialization vector. In light of this limit, what considerations should be made for a TLS 1.2 connection with an AES GCM cipher suite?

  1. Should the session/connection be renegotiated or manually closed when the limit is reached? Or does the TLS protocol specify that the connection will be automatically closed or generate a new IV when the limit is reached? Or is it implementation dependent?
  2. Does the limit apply separately to each peer (server and client) or does the limit apply to the total of all data encrypted on both sides of the connection?
  3. Will resumed sessions use a new key/IV combination thus resetting the count against the limit?
  4. Do AES key size or other cipher suite options affect the encryption limit or answers to the above questions (as long as it's AES GCM)?

Note: Using TLS 1.2 with AES-256 GCM encryption and ECDHE-ECDSA key exchange/agreement via SslStream for .NET 4.6.2.


Actually, that limit does not affect TLS.

TLS encrypts each record separately, using a fresh IV for each. A record is limited to 16kbytes in length, and hence you'll never hit the 64Gbyte limit in TLS. In other words, you'll use a fresh IV after every 16kbytes (and possibly earlier).

  • $\begingroup$ Thanks! That makes life easier. Do you know where in the relevant specs/RFCs this is described? $\endgroup$ – Mike Henry Dec 1 '16 at 22:57
  • $\begingroup$ To answer my own followup question, it looks like the IV is explicitly specified for each record for CBC block ciphers and partially derived from nonce_explicit for AEAD ciphers according to RFC 5246 Section 6.2.3. $\endgroup$ – Mike Henry Dec 2 '16 at 1:01

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.