nonce of AES-GCM in SSL

Question

It seems that the nonce of AES-GCM in SSL has 3 parts:

• salt, 4 bytes, generated in handshake, not changed in whole session
• nonce_explicit, 8 bytes, chosen by the sender and carried in each SSL record
• inner_counter, 4 bytes, used in AES-GCM internal

Is it possible to use a more simple method to construct the nonce:

• generate a 16-bytes IV in handshake
• use this IV as counter for each cipher block in the whole session life, ignore SSL record boundary

then the sender need not carry nonce for each record, saving the bandwidth.

===

I read the RFCs again and found I misunderstood something.

Let me make the question clear.

1. AES-GCM algorithm: require the nonce is distinct.

2. AES-GCM specification [RFC 5116]:

   • It gives an recommended format (not required):

     " When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices, as described in Section 3.2." [ Fixed + Counter ]

     " In some cases, it is desirable to not transmit or store an entire nonce, but instead to reconstruct that value from contextual information immediately prior to decryption." [ Fixed-Common + Fixed-Distinct + Counter ]

   • It is defined for protocols that uses record. I missed this before:

     "Each AEAD algorithm MUST accept any plaintext with a length between zero and P_MAX octets, inclusive, where the value P_MAX is specific to that algorithm. The value of P_MAX MUST be larger than zero, and SHOULD be at least 65,536 (2^16) octets. This size is a typical upper limit for network data packets."

     QUESTION: However if we ignore the specification, is it possible to treat the whole SSL session as a stream (ignore the record bondary), and use only one nonce (and use the nonce as counter) ?

3. AES-GCM in SSL [RFC 5288]: it uses the recommended format.

   QUESTION: since it generates master-secret in each SSL session, it would not hanppen that "multiple devices performing encryption using a single key". Why does SSL use the recommended format (the Fixed part)? What's the function of 'salt'?

I know that since specifications of AES-GCM and SSL have been defined, we should just follow it. I just wonder why it was defined like this.

Besides, maybe we could define an SSL-extension, so that the SSL client and server could use record-seq as nonce_explicit, and do not send it with record.

Answer 1

This is a trickier question than you might think.

The first thing to note is that your scheme doesn't respect record boundaries. TLS 1.2 seems to have been rewritten to use a random IV for CBC mode encryption for each record (to avoid certain attacks). It is therefore likely that the idea of TLS 1.2 is to respect record boundaries.

The document "AES Galois Counter Mode (GCM) Cipher Suites for TLS" - RFC 5288 - mentions "An Interface and Algorithms for Authenticated Encryption" - RFC 5116. This document specifies the use of a 4 byte salt and 8 byte random. That means that the nonce is 12 bytes total, consisting of the persistent part of 4 bytes and 8 bytes random. The GCM specification strongly recommends a 12 byte (96 bit) nonce/IV. This specification in turn is based on GCM ESP, RFC 4106, which specifies the use of GCM for IPsec. So in general the use of GCM in TLS 1.2 seems to follow previously established standards.

The specification of a per record random (explicit) part is of course in line with the cipher suites that use CBC based encryption. In this case however the IV only has to be 8 bytes instead of 16, which saves some 8 bytes as overhead. That's still 8 bytes more than your proposed scheme - which, again, doesn't respect record boundaries - but it's better than CBC.

Notes:

• If you would change to a fully implicit nonce you should still keep to 12 bytes to keep within the GCM specifications. If you would specify 16 bytes IV then the GCM specification requires an additional GMAC. There seems to be no way of specifying a 16 byte counter to be used; the 4 least significant (rightmost) bytes are set by the algorithm itself.
• Related, in your scheme it is impossible to use a GCM API that only allows 12 byte nonces (i.e. without the counter included in the IV). You would need some way of keeping track of the counter and a method of instantiating GCM with that full 16 byte counter.
• In your scheme it would be impossible to parallelize encryption/authentication and decryption/verification unless you had a way to pre-compute the record payload.

In conclusion, although your scheme could work (it's more efficient and isn't likely to be insecure), it doesn't respect record boundaries and it would put additional requirements on the GCM library. Finally, it would not follow pre-established standards for the use of GCM in a transport protocol.

In TLS 1.3 (under construction at the time of writing) it seems that the record number may be used instead of the explicit random, which would require less overhead in the record header and less calls to the random generator.

---

Note that Figure 2 in RFC 5116 "An Interface and Algorithms for Authenticated Encryption" includes the counter in the nonce specification. I've made a report for an ERRATA on this as the GCM specification and the ESP documents both treat the nonce as a 12 byte value (so without the counter).

Answer 2

I just quickly read the TLS specification and the document that introduces GCM into TLS.

It is stated in the definition of GCM-ciphersuites that a 12-byte nonce is supplied (8 bytes per packet and 4 bytes from the handshake, as you correctly stated).

First I'd like to say:
Very often there's a (very good) reason why a decision was made (like here) in something such important as TLS.

Technically your approach would work. (although not accepting record boundaries isn't nice. Maybe cut the stream at the end of a record and increment counter)

Now I'll tell you why TLS doesn't go with something like you proposed but rather with this system:
TLS also has to support CBC mode. (for legacy reasons :-( )
And as the protocol must be very similar for all ciphersuites (no matter wether CBC / GCM / ...) it must provide the most robust IV it can provide (as CBC strongly relies on unpredictable IVs and not just unique ones).

Now let's assume your scheme to work with CBC. You'd ignore record boundaries and hence (in most cases) the delivery and verification of a message has to wait until the next message was delivered, so it's common practice to give each message / record an own IV. But even a continous keystream isn't nice. It introduces dependecies between the messages you want to avoid. You want to be able to read any message if you know the key. If you'd make the IV secret you'd just have an extended key, which isn't a security risk, but might bring practical issues. Now the salt seems to be used to guarantee that IVs are unpredictable (as required by CBC), as an attacker can't know the salt in any case. As 32-bit randomness are fine to make an IV unpredictable the other 64-bits (to 96-bits) are generated separately (at random) for each message. (making it even more unpredictable) However GCM-TLS-Ciphersuite-Documentation allows usage of a counter in TLS (it was for packets I think) to be used as the 64-bit part, so we are back at your proposal which is (somehow) in TLS.

The reason I gave here are only good guesses. To find the real reasons behind all design decisions of TLS one would have to dig through thousands of mails in the archive of the IETF.