# What is the purpose of the “Explicit Nonce” in TLS for AES-GCM and AES-CCM?

TLS uses an explicit (secret) 32-bit nonce in combination with the 64-bit sequence number to create the IV for AES-GCM and the nonce for AES-CCM. However, I wonder why TLS needs the explicit nonce.

In general, the sequence number is used to prevent the reuse of the IV in AES-GCM, or nonce in AES-CCM. The sequence number does not wrap (RFC5246) since the keys have to be renegotiated if the sequence number would exceed its limit. Thus, it should not happen that a sequence number is used twice under the same key.

So why is there an additional 32-bit nonce added to the sequence number?

This additional 32 bit nonce acts as a salt, and makes multicollision attacks $2^{32}$ times harder.

In this attack, the attacker collects a huge number of TLS sessions, each with a record encrypted with the same nonce. He then selects a random key, and generates the counter mode keystream for the key (and the fixed nonce); he then checks if that key stream allows him to decrypt any of the records (and he can do this considerably more efficently than individually checking each one, if we assume that he knows the plaintext for each one, or even if he knows a number of linear equations that holds for each one). If he finds such a random key that matches, he then has the key for that TLS session, and can decrypt it in its entirety.

If the attacker collects $2^n$ sessions encrypted with AES-128, he needs to check an expected $2^{128-n}$ random keys before being able to decrypt one; this is likely still infeasible for any plausible value of $n$, but still is easier than we'd like.

By setting 32 bits of each nonce randomly, this attack becomes more difficult. The attacker needs to select not only random AES keys, but also random 32 bits of the nonce settings, and he'll find a valid decryption only if all those bits are correct; this makes the attack require an expected $2^{160-x}$ random keys. Another way of looking at it; this multicollision attack doesn't make any sense unless an attacker collects at least $2^{32}$ seperate sessions; if he has less, it'd be more efficient for the attacker to select one session, and just brute force that (the 32 bit nonce doesn't make a brute force attack on a single session appreciably more difficult).

Also, it's not really important that the 32 bit nonce is secret; the same sort of logic would work if the nonce was public. However, there's no reason not to make it secret, and it was more convenient in the protocol.

• What if we assume that it's only allowed to send $2^{32}$ messages under the same key. Hence, the sequence number is only 32 bits long. Would the security level be the same as TLS if a 64-bit nonce (32-bit seq + 32-bit implicit) is used? – budderick Sep 23 '16 at 15:27
• @budderick: actually, this multicollision attack doesn't depend on the number of messages per key; it just assumes that we have a single record from each session with (as much as possible) the same GCM nonce (that is, the 96 bit nonce we present to the GCM primitive); by setting 32 bits of that randomly, that's what frustrates this attack. – poncho Sep 23 '16 at 15:34
• The paper of CCM describes in §1.8 that the security level of CCM with $n$-bit keys is actually only $n/2$ because of pre-computation attacks. So does an attacker actually need only $n/2$ sessions or do they refer to a different type of attack? – budderick Oct 6 '16 at 11:27
• @budderick: they appear to be talking about some variant of this attack. Actually, if you continue in that document, they make the same suggestion that TLS does with GCM: 'One solution is to include a random value within the nonce.'; they do add the cavaet that 'a random value in the nonce provides a limited amount of additional security'; however it would appear to me that, in the TLS case, an additional factor of $2^{32}$ is not that limited... – poncho Oct 6 '16 at 12:26