The best option is the second one.
The problem with the first option is that it doesn't provide
the unpredictability property that we need.
If an attacker knows X_0, they can easily compute X_1.
And that's a property our pseudo-random number generator needs to have.
The third option seems reasonable.
It requires a lot of randomness in the pool.
But if we have that much randomness in the pool--to extract
a new random value for each random output--
we should just use that.
If we do have enough randomness for this
there's no reason for all these other steps.
We should just extract something for the random pool each time.
We're not able to do this--we're assuming we don't have enough randomness
to do that. So we're using things that aren't actually random here
if we're extracting them from the random pool more quickly
than we're actually able to produce new randomness here.
It's doing a lot of extra work, but it's eventually starrting to use values
that are not random as the inputs to our encrypt.
And if those values are predictable, well then the outputs become predictable, too.
So that doesn't work--so the best solution is this middle one
where we're extracting the seed once, we're reusing that seed,
and we're encrypting a sequence of values which is--can just be a counter--
and each time using the output of that encryption.
