0
$\begingroup$

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?

$\endgroup$
2
  • $\begingroup$ 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? $\endgroup$ – SEJPM Sep 21 '20 at 9:29
  • $\begingroup$ 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. $\endgroup$ – TrinityTonic Sep 24 '20 at 7:17
1
$\begingroup$

The standard rule is simple: Re-key whenever the sequence counter would (likely enough) repeat. For incrementing sequence counters this should be the case when they overflow.

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.

$\endgroup$

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.