Since reusing IVs is death for AES GCM, it seems like using the fixed IV in the TLS connection state is a phenomenally bad idea. It wouldn't even seem to be a good idea to use the salt + counter method since an attacker could watch for the first ciphertext record exchange and keep track from there. Is there an extension to address this? The RFC is distinctly unhelpful.

  • $\begingroup$ Could you clarify the concern you have? The IV in TLS is made up of a salt and a counter. The same key and salt are only used for one connection (the server and client have different salts), while the counter is required not to repeat. $\endgroup$
    – otus
    Commented Jul 27, 2016 at 4:26
  • $\begingroup$ Had a lot of stuff going on, so sorry for the late response. You and Makif answered this for me. Thank you. The part I was missing was that the salt is simply a piece of the server and client IVs that are derived during the PRF process. $\endgroup$
    – Steve B.
    Commented Sep 12, 2016 at 4:36

1 Answer 1


You can check this answer which mentions how does the IV generated for GCM ciphers in TLS 1.2

... is an AEAD Cipher, so it is in the form of GenericAEADCipher:

struct {
     opaque nonce_explicit[SecurityParameters.record_iv_length];
     aead-ciphered struct {
         opaque content[TLSCompressed.length];
  } GenericAEADCipher;

Here, the nonce_explicit contains 8 byte nonce, and you combine this with the 'fixed IV' from key derivation (4 bytes) then you get 12 byte IV for AES-GCM mode encryption. (Note that you only sent the last 8 bytes of the IV).

Also, from the RFC 5288 (AES Galois Counter Mode (GCM) Cipher Suites for TLS)

6.1. Counter Reuse

AES-GCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse.

From Section 3 of the RFC 5288:

The "nonce" SHALL be 12 bytes long consisting of two parts as follows: (this is an example of a "partially explicit" nonce; see Section 3.2.1 in [RFC5116]).

struct {
     opaque salt[4];
     opaque nonce_explicit[8];
} GCMNonce;

The salt is the "implicit" part of the nonce and is not sent in the packet. Instead, the salt is generated as part of the handshake process: it is either the client_write_IV (when the client is sending) or the server_write_IV (when the server is sending). The salt length (SecurityParameters.fixed_iv_length) is 4 octets.

The nonce_explicit is the "explicit" part of the nonce. It is chosen by the sender and is carried in each TLS record in the GenericAEADCipher.nonce_explicit field. The nonce_explicit length (SecurityParameters.record_iv_length) is 8 octets.

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

So, reusing the same IV in GCM ciphersuites in TLS is prevented in this way.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.