AES-CTR Mode, Predictability of Nonce

Question

I'm trying to rebuild AES-CTR mode and have some questions concerning the generation of the nounce.

I've comonly seen the nonce be distributed like this $Nonce_{128\,bits} = IV_{64\,bits} \mathbin\Vert Counter_{64\,bits}$ where the IV is randomly generated foreach message and the Counter incremented foreach block of the message.

So, if the Nonce can be shared clearly on the network :

• is there a problem if the Nonce is predictible (never the same Nonce + Key but the adversary can predict them in advance) ?
• if not, why don't we use a simple $2^{128}$ counter starting at 0 and reset it every time we change the key ?

Thanks for your replies.

Update: so, according to your response, if I were to use a Linear Congruential Generator (which is not cryptographically secure) with the right parameters to get sufficient periodicity (superior to the number of messages I want to send) to get each and every nonce, It wouldn't compromise the security of the scheme ?

Answer 1

I've comonly seen the nonce be distributed like this $Nonce_{128\,bits} = IV_{64\,bits} + Counter_{64\,bits}$ where the IV is randomly generated for each message and the Counter incremented for each block of the message.

Most of the API's that I've seen implement an IV the size of the block cipher, usually $n = 128$ bits. This IV is build up by a nonce and a counter. Where the split is depends then entirely on the user.

Most API's also assume that the counter block is considered big endian and that the counter operation is performed modulo $2^n$. The user is therefore completely responsible for making sure that the counter blocks won't overlap as the cipher can basically encrypt any sized message.

Is there a problem if the Nonce is predictable (never the same Nonce + Key but the adversary can predict them in advance)?

With any common block cipher mode of operation the IV, including nonce and counter can be public. Some modes like CBC do indeed require the IV to be fully unpredictable (which translates to randomized) but CTR mode is not one of them.

If not, why don't we use a simple $2^{128}$ counter starting at $0$ and reset it every time we change the key?

We could, but that would require to share state between the messages. Generally you'd want to use a cipher context (or object) per message, and keep those cipher context separate - excepting for the key. However, as long as you don't reuse the key stream generated by counter mode then you'd basically be OK.

As a side note: we generally prefer authenticated ciphers nowadays; those may well use CTR mode as implementation detail, but that detail would be mostly hidden to the user.