Why do we need nonce in the CTR mode given that Deterministic counter mode is semantically secure?

Question

In the CTR mode, a nonce, a counter value and the key are needed to form the input of the PRF. However, the Deterministic counter mentioned in Dan Boneh's slides (https://crypto.stanford.edu/~dabo/courses/OnlineCrypto/slides/04-using-block-v2-annotated.pdf, pp. 20), does not have the nonce. It only uses the key and the counter value as the input of the PRF. If I'm not mistaken, we can say that given a PRF $F$ and a key $k$, a pseudo-random number is generated by $F(k, g(nonce, counter\_value))$ in CTR mode, while deterministic counter mode uses simply $F(k, counter\_value)$, without the presence of nonce.

According to the slides pp. 21, Deterministic counter mode is already semantically secure. So why do we need a nonce in the standardized CTR mode?

Answer 1

According to the slides pp. 21, Deterministic counter mode is already semantically secure. So why do we need a nonce in the standardized CTR mode?

If you use a 128-bit nonce that also acts as the counter, you cannot increment the nonce in the same endianness as the counter. If you did, you'd end up using the same nonce, which is insecure.

If you can guarantee that the 128-bit nonce will be unique (e.g. a different key for each encryption operation or random nonces only a certain number of times), it's an acceptable practice.

The problem with AES-CTR is that there's variation in nonce size between implementations. It can be 64 bits, 96 bits, or 128 bits. I would consider this a weakness as it causes confusion and interoperability issues.