IV/Nonce in CTR&GCM mode of operation

Question

We know reusing IV can compromise our secrecy. I have some questions aiming to clarify the use of an IV/Nonce in CTR/GCM:

1. Is it OK to use the same key for encrypting plain-texts in authenticated encryption (GCM) and confidential only encryption (CTR) if we use a random IV to encrypt each plain-text? How many time we can reuse the same key in this way?

2. What's different between "IV" and "nonce" in CTR or GCM mode? (I know there is a counter within the algorithm, but there is some IV before the counter to encrypt each block. From Wikipedia, I thought the correct term was IV+counter instead of saying nonce?)

3. What is the right way to generate the IV for CTR or GCM modes? Should we use a TRNG or CSPRNG? Some comments imply the nonce shouldn't be random - why is this?

Answer 1

IV (initial value or initialization vector) is a vague term that describes some kind of starting value for a mode of operation that is known to both parties, and generally sent in the clear with the encrypted data (and known to the attacker)

IVs in many modes of operation have specific requirements to that mode. In some modes the requirement is that is unpredictable and (with high probability) not reused. For those modes the easiest method for IV generation is a CSPRNG, with this method IV reuse can occur due to the nature of random numbers. For CTR and derivatives, the IV must be a nonce, which is a very specific type of value, and is commonly referred to us such for these modes, as to prevent confusion regarding the requirements. NIST uses both names in the GCM spec document, but is clear on the requirements.

A different way of generating IVs that are unpredictable and also unique is to encrypt a counter value with a different key. These are the length of the block size.

A nonce (number used only once) must NEVER be reused with the same key (hence the name), since it is the plaintext input to the block cipher. Modes that use a nonce rather than a random number include OFB, CTR, and CFB. CTR has no requirement for nonce unpredictability. The nonce for CTR is generally a sequential message counter starting at 1. This also allows easy verification in some applications that a message is not received multiple times (replay attacks). The block counter is for the blocks within each message. If the nonce were chosen randomly, the probability of overlap increases with each encrypted block; this is not a problem if a record of each nonce was kept and verified to ensure it was not reused.

CTR mode generally uses a 96-bit nonce, leaving 32 remaining bits for the block counter. This gives 64GiB of output blocks per nonce before the nonce must be incremented, which is enough for the majority of uses. The secure limit on output for CTR is the secure limit for block cipher output with a given key, which for AES is a maximum of $2^{128/2}$ blocks.

The other requirement for nonces specific to GCM is that it is not all 0 bits, as that is used for GHASH, and using it can possibly allow forgeries of all authentication tags. This value is essentially the IV to the GHASH function, which is unique to each key/block cipher combination.

When used with GHASH in GCM, CTR mode has a more limited secure output, and this depends both on the size of the nonce as well as the size of the authentication tag. The smaller the tag, the fewer messages can be transmitted before attacks become successful. Additionally, using different tag lengths with the same key can lead to a loss of security. See Authentication weaknesses in GCM for details on attacks on short nonces. For GCM The maximum plaintext length is $2^{39} - 256$ bits for a given nonce.

I do not see any problem with using the same key in GCM and CTR, as long as there is no nonce overlap, and you stay within the safe block limit for AES, as well as the safe limit for the GCM authentication tag generation with a single key, and never encrypt an all 0 input. The GCM special publication (800-38D) from NIST regarding key and nonce generation however does specify that the key shall only be used with GCM and no other mode, I would be inclined to follow this advice.

Answer 2

1. Yes, as long as you obey all the total usage limits and choose the IV appropriately (see below).
2. Whilst IV is a general term for any initialisation vector the recent trend has been to use the term 'IV' to refer to a random vector, and "nonce" (a contraction of "n-umber used once") to refer to an input vector that need not be random, but cannot be repeated. In each case we assume that the adversary is allowed to learn it, and under some attack models we even let the adversary choose it. If one looks at the security claims of a mode of operation they will generally present their results based on some assumption on the IV. In the case of counter mode or its derivatives (of which GCM is one), we assume that the IV is a nonce.
3. This question is a duplicate of point #3 and has a good answer.

So, the gist of it is: CTR requires a unique nonce with each encryption, which the adversary is allowed to know or predict. How do we implement this? Well, the simplest way is to maintain a counter outside the main algorithm (This is distinct from the internal counter used within the mode). That is, each time you encrypt more data, you also increment the nonce. By doing this, you know that the value will indeed be a nonce, until it rolls over at which point you must change key.

Why doesn't a random IV work for this? In short, because of the birthday bound. If we randomly choose an $n$ bit IV, after roughly $2^{n/2}$ IVs have been chosen, we expect to generate an IV that is not new. This would clearly not be a nonce, leading to a breakdown in the security of the mode. In the case of GCM, this means you cannot expect security beyond $2^{96/2}=2^{48}$ messages if using random IVs.