Why is there a counter in CSPRNGs? This is probably one of those embarrassingly simple questions, but here goes.  Consider the following two constructs:

CSPRNG made out of a block cipher (AES) with a counter such as




CSPRNG made out of a secure hash function with a counter (Java SecureRandom's SHA1PRNG) such as





The common denominator is the provision of a counter.  What's the point of the counter as you could simply do state' = F(state) once you have state established?  So the state would be the seed alone, and it would be iteratively processed to produce the random stream. What does the counter bring to the party?
A counter has a practical advantage: it makes a random stream seekable instead of purely sequential. Which doesn't matter for a CSPRNG but does for a DRBG and parallelization.

But it also works around two possible issues with recursive calls to a hash function: the cycle length, and fixed points.

Hitting a fixed point would be particularly nasty; what should have been a random number generator would start generating the same value forever.

In practice, the risk is negligible unless your function is not a secure hash function, or has a really small block size. The cycle length is not an issue either, if only because storing all the observed values before biases become exploitable is not practical.

Still, using a counter is reassuring. Hitting a fixed point would have zero security implications. Neither would a point with a very short cycle length.