Of the use of unpredictableSeed

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/05/2017 07:25 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sun, Mar 05, 2017 at 10:30:29AM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
> [...]
>> Another good thing pointed by the article would be to use the Mersenne
>> twister for unpredictableSeed, which would make it difficult to infer
>> the sequence from a few samples. Please share if that would be a good
>> thing to do.
> [...]
>
> Wait, isn't that missing the point?
>
> I thought the whole point of the article was that you shouldn't be using
> unpredictableSeed as your PRNG.  It's only supposed to give a
> random-enough value to get your chosen PRNG into a (hopefully)
> unpredictable initial state. But you should be using values from the
> PRNG, not from unpredictableSeed!  Otherwise that's totally missing the
> point.
>
> It's possible to use unpredictableSeed for occasionally reseeding your
> PRNG, but that should be quite infrequent.  If you find yourself
> reseeding your PRNG every other minute, or worse, every time you call
> your PRNG, then you're doing something very, very wrong.
>
> Using the Mersenne twister to generate unpredictableSeed seems to me to
> be completely backwards.  It should be the other way round: the value of
> unpredictableSeed should be random enough to be suitable for seeding a
> Mersenne twister algorithm, so that it will start off the algorithm in a
> random initial state (and you should be getting values from the
> algorithm thereafter, not from unpredictableSeed).

Well, the big point is that nothing involving seeds should come near 
anything security-releated. Then secondly, (like you say) don't use any 
initial-seed-getter *as* an RNG.

But that aside, *if*[1] we do want to increase the entropy in 
unpredictableSeed, we should use /dev/(u)random and _RtlGenRandom. Like 
you say, anything less is kinda missing the point (unless someone can 
argue the current one is insufficient for non-security randomization).

[1] And I'm not sure we necessarily do want to. Current 
unpredictableSeed seems good enough as-is for non-security purposes, and 
we don't want to give people more reason to erroneously think it's ok to 
use unpredictableSeed for salts, tokens and the like.