On: A Family of Better Random Number Generators

[Thorrez]

Why does back off / retry require unpredictability?

[thiagocsf → Thorrez]

To avoid a stampede of requests by synchronised clients.

[Thorrez → thiagocsf]

That doesn't require unpredictability. For example, Mersenne Twister seeded from /dev/urandom would work fine for that, even though it's predictable because Mersenne Twister is predictable.

[mytailorisrich → Thorrez]

It does not require true unpredictability, the key aim being to have each host retry at a different time.

There is no need to cryptographic strength, which is costly, and pseudo-randomness is enough and much cheaper.

[Thorrez → mytailorisrich]

I think you're agreeing with me that unpredictability isn't necessary (e.g. Mersenne Twister would work fine).

[DougBTX → Thorrez]

I see you’ve replied to quite a few of the comments in this thread, but I think the basis of the disagreement isn’t in the specifics, but because you’re using a stronger definition of “unpredictability” than they are.

[Karliss → DougBTX]

Today I learned that there are other aspects for CSPRNG beside the stronger definition of unpredictability. Wikipedia mentions inability to calculate previous values in case the hidden internal state gets revealed. So I assumed that top question was intentionally asking about weaker definition of predicatability not PRNG that have good enough unpredictability for CSPRNG but doesn't match other requirements.

[Thorrez → DougBTX]

I believe I'm using the same definition of unpredictability as the website. If other people are using other definitions that is indeed going to cause a lot of confusion.