unpredictableSeed

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sun Mar 3 02:42:08 PST 2013


On 03/03/2013 09:58 AM, Ivan Kazmenko wrote:
> I have to ask: what would be a good unpredictableSeed by definition?  With the
> current implementation, three downsides come to my mind:
>
> 1. Process ID, thread ID and system tick are insecure sources of randomness and
> can provide just a few bits of randomness in certain situations.  I don't know
> how to address this in a portable way.
>
> 2. Once we know the first seed, it is easy to predict all subsequent seeds.  A
> solution would be to use a secure RNG instead, not just the one which gives away
> its state.

I have to say that in my case, I'm not interested in security, but merely in 
having a statistically good enough seeding for parallel simulations.  That is, I 
want multiple parallel streams of random numbers that are independent to the 
highest possible degree.

But, you have a point, and if unpredictableSeed is good enough for my 
application, it may not be good enough for others.  (Though I'm not sure e.g. 
Mersenne Twister is adequate for crypto in the first place.)

That said, is it as un-random and predictable as you say?  I'd have anticipated 
that the combination of process ID, thread ID and system tick would generate 
quite a good seed for Mersenne Twister, but I don't have the theoretical 
argument to back it up. :-(

> 3. It would be a particularly bad idea to initialize MinstdRand0 instances with
> consecutive unpredictableSeeds and then consider them independent.  This is just
> a consequence of a particular choice of RNG on the previous step.

Is MinstdRand0 really something you should consider using at all, if you care 
about quality statistics?

> So, which of these do you consider the real problems, and what more do you need
> from unpredictableSeed?

I need _statistically_ thread-safe pseudo-random number generation for the 
purposes of scientific simulation -- so, I don't care about the theoretical 
predictability, but about the quality of approximation of randomness.  I'm using 
rndGen (so, Mersenne Twister on my x86-64 system) with anything from 2-20 
different threads.

My broader interest here is more theoretical, though, because I'd like to see 
std.random equipped with the best possible tools for the job -- and there are a 
number of existing niggles with it that spark my paranoia about other aspects :-)


More information about the Digitalmars-d-learn mailing list