Does the Windows RNG have security problems?

The Windows RNG infrastructure is specified in this article. On page 4, it states that the PRNG called AES_CTR_DRBG is used (with 256-bit security strength).

According to Wikipedia, this PRNG has security problems when used with certain parameters.

Specifically:

When AES is used as the underlying block cipher and more than 128 bits are taken from this pseudorandom number generator, then the resulting security level is limited by the block size instead of the key size and therefore the actual security level is much less than the security level implied by the key size.

The source for this text on Wikipedia is this article.

In my understanding, pseudorandom number generators are often used to produce thousands of random bits before reseeding, and thus many more than 128. Does this mean that the Windows RNG is unsafe?

Update

I edited the phrasing of the Wikipedia page.

Does this mean that the Windows RNG is unsafe?

No. This would be drawing incorrect conclusions from the correct facts stated in a misleading way by the Wikipedia article as it stands now.

Truth is, the combination of the whitepaper and the paper given as reference show that it may exist a mean to distinguish a huge block of data generated by a Windows RNG in a single call, from a truly random block of data, even so slightly better than at random. There is no risk whatsoever that it degenerates into an exploitable vulnerability.

The root of the (non-)issue is that, unless the whitepaper leaves some detail unstated, large blocks of randomness generated by a single call are the output of AES in CTR mode, thus no 128-bit sub-block repeats; when that could happen in true random data.

That's a distinguisher, but it's far from exploitable when we take into consideration that there are limits to the size of data blocks that can be generated in one invocation of the DRBG.

If we assume a 4TiB block (Windows 11 Entreprise can have 6TiB RAM installed), that's $2^{37}$ sub-blocks, thus the probability that a sub-block repeats is close to $2^{2\cdot37-1-128}=2^{-55}$. Thus after $2^{22}$ (>4 million) such attempts with a true RNG, we have probability close to $2^{-33}$ (one against the number of humans now on earth) there is at least one repeat in at least one of the experiments. But that probability is zero if we use the Windows RNG (and it works as I understand from the description).

So if we did that experiment (which would hog many expensive computers for a ridiculous amount of time),

• If we do not see any repeated block, we should be as surprised as we should be to NOT be picked in a random draw among all humans on the planet. Which is, not surprised at all, and entirely unable to draw any useful conclusion from the expensive experiment.
• Otherwise, we can safely conclude that the Windows RNG does not work as I thought it does, or that the computer that spotted the match had a failure, or there's some subtle mistake in the code that detects identical sub-blocks (which takes much longer and a little more RAM than generating them).

In either case, there's not the slightest practical security implication when it comes to Window's use of CTR_DRBG, because it uses a 128-bit cipher and reseeds the counter so much before $2^{64}$ blocks are generated.

The paper used as reference aims to show a certificational weakness of NIST's CTR_DRBG, and that NIST was wrong about how it certified it. It's not about drawing any operational conclusion. Except perhaps to not trust NIST recommendations when it comes to random number generator. But that's common sense for one that looks at the volume of these recommendations, or/and at the DUAL_EC_DRBG debacle.

I'm very certain it's a editorial error. Typical CTR-DRBGs instantiated with an 128-bit blockcipher use 32-bit counter, and lets you pull out 4 GiB of data safely before needing to reseed.