# Key renewal when the sequence counter is only 32-bit

If we look at the use-case that our sequence counter within our TLS communication is only 32-bit, would an automatic key re-newal be necessary a lot more frequently? We're going to use state-of-the-art algorithms consisting of AES-GCM (at least 128-bit keys) and HMAC-256. I'm referring to the answer posted here - https://security.stackexchange.com/questions/55454/how-long-does-an-https-symmetric-key-last - where it states that key renewal would not be necessary due to the substantial amount of data that can be encrypted with AES without the necessary need for a key renewal.

The sequence counter is not the one used within TLS but a protocol specific one. We're not sure if we continue with the "normal" TLS handling after the handshake has been done. We're going to use EAP-TLS for the handshaking. So we don't know if we make use of the implicit 64-bit sequence counter of TLS - would this make a difference for the question asked above?

• I'm a bit confused. Have you layered your own (GCM-based) encryption on top of TLS with a 32-bit sequence counter? Or are you asking how often to ask your TLS library to update the symmetric keys? Or something different? – SEJPM Sep 21 '20 at 9:29
• We use EAP-TLS for connection establsihment and after that use our own scheme which has a 32-bit sequence counter within the message frame. – TrinityTonic Sep 24 '20 at 7:17

If you're using AES-GCM and you were to pick the (96-bit) nonces randomly, re-keying after $$2^{32}$$ messages would be recommended. However given that you appear to use an actual counter and feed it into GCM's nonce input re-keying on wrap-around is good enough - which incidentally for 32-bit counters would also happen around $$2^{32}$$ messages.
If you used a 64-bit counter, the previous thought would extend somewhat and a re-key would be required at last every $$2^{64}$$ messages. However for reasons of the security proof you should really re-key after hitting $$\sigma+q=2^{48}$$ with $$q$$ being the number of nonces encrypted and $$\sigma$$ being 1/16th of the total number of bytes encrypted while not encrypting more than 64GiB per nonce-key pair.