Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
In TLS 1.3, it seems that nonces for AEAD are constructed by XORing the recorded sequence number with the server/client_write_IV (which is generated during the handshake). Thus, nonces are random-looking and cannot be reused as the sequence number monotonically increases.
Why not just use the sequence number? Is there an advantage of having a random-looking nonce for AEAD? If not, how to explain this implementation choice?
As @CodesInChaos mentions in the comment, the purpose of the nonce randomization in TLS 1.3 is to combat multi-user attacks. That is, attacks where the adversary attacks multiple users simultaneously, and is happy as long as it breaks at least one user's connection without any regard to which user this is specifically. This motivation is explicitly called out in the RFC (Appendix E.2):
In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key (as is commonly the case for HTTP), the nonce is formed by mixing the sequence number with a secret per-connection initialization vector derived along with the traffic keys. See [BT16] for analysis of this construction.
The idea of randomizing the nonce has received analysis in two academic papers:
Mihir Bellare and Björn Tackmann. The Multi-user Security of Authenticated Encryption: AES-GCM in TLS 1.3. CRYPTO'16. ePrint link
Viet Tung Hoang, Stefano Tessaro and Aishwarya Thiruvengadam. The Multi-user Security of GCM, Revisited: Tight Bounds for Nonce Randomization. CCS'18. ePrint link
An AEAD relies on no reuse of the same pair of key and nonce. Reusing the same key and nonce would be catastrophic.
TLS 1.3 uses the same key for multiple records, but constructs a nonce from a sequence number and a pseudorandom base value that is derived from the current traffic secret.
Using a sequence number ensures that the same nonce is never used twice with the same key. It also avoids the overhead of having to transmit a nonce over the wire, saving numerous octets per record.
The possibility of using just a sequence number was considered, but there was a concern raised that early plaintexts are often predictable. Having a fixed nonce might expose the protocol to pre-computation attacks (where, for example, the encrypted value of GET / HTTP/1.1\r\n is stored against a large number of different keys). An unpredictable nonce makes it harder to mount that style of attack.
Such an attack is likely infeasible. 2128 is considered an impractically large table. Relying on a smaller table and the birthday paradox still means 264 entries and the same number of connections. An abundance of caution suggested that the modest cost of a defense was justified.
Since nonces for AEAD are sent in cleartext and they are public, using sequence numbers as nonces gives information to an attacker about the traffic. Simply XORing sequence number with an IV makes sequence number implicit to the network.
