#679 random seed in globals and randomvar lack entropy

[David P. Chassin]

If gridlabd is run twice in the same second, the random numbers come up the same even when they should be different. Recommend added additional sources of entropy in the srand() calls. Consider the pid, macaddr, and/or usec as additional sources of entropy.

[David P. Chassin]

• status changed from new to accepted

Started with changeset:3750

[David P. Chassin]

• status changed from accepted to closed
• resolution set to fixed

As of changeset:3751 there is an entropy source that includes the pid and time.

The current solution is much better, but not ideal: the behavior of this new entropy_source() call is not well-defined if called more than once per run (which is possible). If the entropy source is called twice in the same run in less than a second, it will return the same number. But if it's called twice in the same run more than a second apart it will return a different number.

[Andy Fisher]

It appears as if this one has been fixed but not merged into trunk. Can you confirm this?

[David P. Chassin]

I doesn't look like this has been fixed. I suggest using the microseconds also, this still leaves a potential lack of entropy if the call occurs twice within 1 microsecond, but that is very much less likely to occur than twice in 1 second.

[Andy Fisher]

per Daves previous remoarks I'm reopening this ticket. However, It is at a stage where we can merge it with trunk and then reopen the ticket after the knothole.

[Andy Fisher]

I just performed a code compare. The work done in this ticket is already in trunk. So I will be deleting this ticket. It will be reopened after the knothole.

[David P. Chassin]

Here is the proposed for this entropy_source function in core/random.c:

unsigned entropy_source(void)
{
        struct timeval t;
        gettimeofday(&t,NULL);
        return (unsigned)(getpid()*t.tv_usec);
}

[David P. Chassin]

By the way, this has not been addressed in trunk. The problem persists but the fix is trivial.