This will depend on the length of the nonce (which depends on the algorithm). With shorter nonces (64 bits), it is strongly recommended to use a counter. You c

This will depend on the length of the nonce (which depends on the algorithm). With shorter nonces (64 bits), it is strongly recommended to use a counter. You can start at zero, or if you prefer, start at a random number or use a LFSR whose cycle is 2^64. That way you know for sure that the first 2^64 nonces are all unique. If random generation was used, you would hit collisions due to the birthday paradox, and by 2^32 nonces the chance of a collision would be about 40% [1]. With long nonces (192 bits), you can use random generation entirely, given that you have a good CSPRNG. With intermediate nonces, it might be reasonable to use a 64-bit counter and either randomize the rest or use clock data (if you have a system with good clocks). This gives a little protection against any sort of nonce-reset bug in your code, while still giving you a full 2^64 nonces before the counter cycles. But this is just my own opinion, and I'm not a professional cryptographer (although I did study under Philip Rogaway). It seems imminently more likely for a counter to get reset by a code bug (e.g. KRACK), then for a largish random number to repeat, so I understand why coders instinctively lead towards random numbers rather than counters. [1] https://eprint.iacr.org/2016/475.pdf https://eprint.iacr.org/2016/475.pdf, see table page 6