2

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?

Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
user12036
  • 29
  • 1
  • 3
  • 1
    Yes, random IV works. – K.G. Feb 17 '14 at 08:45
  • Yes, random IV works for a wide-enough block cipher like AES, and a practical definition of unlimited, and the TRNG used is working properly. Like, you encipher $n$ 16-byte blocks, and are content with a residual risk of $2^{-128+2\log_2 n}$ (that is for short messages; risk is appreciably lower for long messages). – fgrieu Feb 17 '14 at 09:31
  • Most of the time – yes… but that will strongly depend on the cipher you use (as @fgrieu indicates). Not knowing the specific cipher, the question seems to be a bit broad to some. Maybe you could edit your question and mention the cipher are you using (or planning to use)? – e-sushi Feb 17 '14 at 09:56
  • (not related to key..) For CTR and GCM the "IV" is a nonce, therefore random selection is not a good idea, as that can lead to reuse with a probability higher than if it is chosen sequentially or in a way where reuse is not possible. The answer to the actual question is no for GCM, hopefully someone will elaborate, see http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf – Richie Frame Feb 17 '14 at 10:09
  • 1
    [at]fgrieu from TRNG you mean CSPRNG? @e-sushi i talking about AES. [at]Richie Frame what's difference between IV and nonce? if we don't choose it randomly how we can prevent reusing an IV??! – user12036 Feb 17 '14 at 10:18
  • TRNG = True random, not pseudorandom. A nonce is a number used only once, and does not need to be "random". An IV for modes such as CBC should be "random" and unpredictable. Nonces can be sequential, thus there will be no reuse. Typical nonce size for CTR is 96-bits, thus random choice of nonce is much more likely to cause reuse than a a 128-bit IV. Nonce reuse is worse than IV reuse. – Richie Frame Feb 17 '14 at 10:26
  • @Richie Frame do we have IV too beside a counter nonce in modes like GCM? we can't generate IV by CSPRNG? TRNG seems very expensive – user12036 Feb 17 '14 at 10:29
  • No there is not an IV for CTR, just the block cipher input and key, and the input is the nonce plus the block counter (the other 32 bits). – Richie Frame Feb 17 '14 at 10:34
  • @Richie Frame same thing for GCM ? no IV? if they have no IV so key reuse won't harm ?! – user12036 Feb 17 '14 at 10:45
  • I suggest changing the question to: "Up to what limit (number of plaintexts, length of that, acceptable residual risk..), and subject to what condition(s), is it OK to use the same key for encrypting plain-texts in authenticated encryption (GCM), or confidential only encryption (CTR), if we use random IV to encrypt each plain-text?". That makes an answer more useful, falsifiable, and significantly more difficult. – fgrieu Feb 17 '14 at 10:52
  • GCM has no additional required inputs over CTR other than the data length. I agree with fgrieu that the question should be much more specific. – Richie Frame Feb 17 '14 at 10:59
  • GCM IVs are typically 96 bits, which is rather short for random generation. – CodesInChaos Feb 17 '14 at 14:02
  • @CodesInChaos 96 bit have a good entropy to be different things, how its short? – user12036 Feb 17 '14 at 16:46
  • See the page linked from my answer. Basically (because of the birthday bound) if you want your IV to be both random and a nonce you need to double the bit-length. – Cryptographeur Feb 17 '14 at 18:06
  • In scenarios where you want random IVs, you probably can afford a hashing operation per message, so you could derive a per-message key from a master key and a longer per-message random value. – CodesInChaos Feb 17 '14 at 18:32

2 Answers2

2

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.

Richie Frame
  • 13,097
  • 1
  • 25
  • 42
  • can you briefly explain how exactly nonce in CTR mode is generated ? its just a sequential value or a random value or both XORed ? – user12036 Feb 17 '14 at 13:16
  • It is a sequential value with a given starting point, which can be 0x000000000000000000000001 or some random value. As long as the combination of nonce/iv and block counter is never used twice with the same key, CTR has no other input requirement. You could use 128-bit random values if you wanted, as long as you keep track of all of them. – Richie Frame Feb 17 '14 at 20:10
  • @RichieFrame Can you please point me to the document stating that GCM nonce cannot be all 0 bits? I guess I must have overlooked that in the SP800-38D. – Paya May 27 '15 at 16:54
  • @Paya that note was in regards to the full 128-bit internal IV; the GCM specification prevents using an all 0 IV by starting the block counter at 1 when using a 96-bit all 0 input IV, and running GHASH on an input IV of more than 96-bits, thus turning it into a nonce with regards to H. – Richie Frame May 27 '15 at 20:18
1
  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.

Community
  • 1
Cryptographeur
  • 4,317
  • 2
  • 27
  • 40
  • I think $2^{48} = 281,474,976,710,656$ would be too optimistic, A $p=10 x 10^{-6}$ probability of collissions would happen after $\sqrt{2 * 2^{96} * ln(1 / 1 -10 ^{-6}}=39.806.582.904$ draws. – eckes Dec 01 '15 at 23:35
  • @eckes, could you explain your equation? – Ursa Major Mar 04 '17 at 16:53
  • @UrsaMajor it was one of the birthday approximations. If you look at the Wikipedia article it lists for 96 bits and 10^-6 collision probability a 4*10^11 number of elements, which seems to match my calculation. 10^-6 was just a possible good certainty. – eckes Mar 04 '17 at 18:13