On Tue, 3 Nov 2015, Colin Putney wrote:

> 
> 
> On Mon, Nov 2, 2015 at 4:32 PM, Levente Uzonyi <leves at elte.hu> wrote:
>       Hi All,
>
>       With the recent UUID changes, we're facing the problem of properly seeding a Random instance. The current method provides only 2^32 different initial states, with which the chance for two images to have the
>       same values on startup is way too high (~9300 startups for 1% chance of collision).
>       To avoid the collisions we need a reliable source of random bytes.
>       Currently we have the following sources:
>       1. /dev/urandom: fast, reliable, but not available on all platforms (e.g. windows).
>       2. UUIDPlugin: fast, but this is what we wanted to get rid of in the first place, so it may not be available.
>       3. Audio recorded through SoundSystem: slow, unreliable, and it may not be available.
>       4. Time primUTCMicrosecondClock. On its own it has way too little entropy. We can still use it to initalize the PRNG by using additional sources of entropy (image name, path, vm version, whatever). We can use
>       SHA1 to get "more random" bits from out entropy sources. But this is more like a last resort than a solution to rely on.
>
>       So I suggest we should create a new primitive, which can fill a given indexable object (bytes and optionally words) with random values - the same way Random >> #nextBytes:into:startingAt: works. It could use
>       CryptGenRandom on Windows, and /dev/urandom on other unix-like platforms.
>
>       As fallback mechanisms, I'd implement 1. 2. and optionally 4., and use them in the given order. The drawback of these mechanisms is that they create unwanted package dependencies, because Random is in Kernel,
>       while most potetial sources of entropy, along with SHA1, are in other packages.
> 
> 
> Why do we want to get rid of UUIDPlugin? Is it just because fewer plugins is better, or is there a problem with this one in particular?

UUIDPlugin has both compilation and dynmic linking issues on some 
platforms. I'd still use it if it's available, unless we have a primitive 
to provide random bytes, because 16 random bytes make a V4 UUID (-6 bits).

> 
> Also, if we're going to have a primitive that supplies fast, high-quality, random bytes, shouldn't Random just call that for random values, rather than seeding a PRNG? 

You still need a way to convert those bytes to numbers.
And stateful PRNGs better for testing. When there's a test failure, you 
can generate the same "random" input to reproduce it.

> 
> That said, I think I'd do seeding using
> 
> 1. the primitive, if available
> 2. UUIDPlugin, if available
> 3. The current method
> 
> Most VMs will have either the primitive or the plugin, so the current method will be used rarely, and thus collisions will be very rare. Keep it simple. 

What do you mean by "current method"?

Levente

> 
> Colin
> 
>