Correct. However, some implementations actually incorrectly refer to the nonce as an "IV" (initialization vector), where it's not so obvious.
Also, it's not entirely clear just how bad a reuse actually is. For example, in AES-CBC, reusing the IV has much less impact than reusing the nonce with AES-GCM.
Aside from just not understanding it, it's plausible that someone would generate nonces weakly, say, from a weak source of randomness.
Even using a strong source of randomness for an AES-GCM nonce is weak over enough messages, since it only gets you 48 bits of collision resistance.
If you're not using random nonces, maybe you want to use a counter, and then you have to worry about race conditions, state resets, etc. (if your system lost power immediately after using nonce n, would it boot back up and reuse it?)
> Aside from just not understanding it, it's plausible that someone would generate nonces weakly, say, from a weak source of randomness.
This is actually generally fine for nonces (used in CTR and GCM modes, and in ChaCha20). Typically the only requirement for a nonce is that it is only used once. It is even safe to use a simple incrementing counter.
IVs, on the other hand, are required to be cryptographically random.
My point is that a random AES-GCM nonce is a problem because you will end up re-using nonces by chance, assuming multiple messages are being encrypted with the same key. Due to the small nonce size, this is still a problem even with secure randomness, it's just even more of a problem with weak randomness.
Whoops, sorry. Slept poorly last night and missed this. You're 100% right, GCM doesn't have enough bits in the nonce to safely generate them randomly for any case where keys are reused significantly.
Also depending on the cryptosystem, nonce requirements vary wildly. For example using 1, 2, 3, 4... as a nonce for CTR is a recipe for disaster, but it's fine for many asymmetric ciphers.
