[Vm-dev] Re: [squeak-dev] Seeding instances of Random
btc at openinworld.com
Tue Nov 3 15:24:53 UTC 2015
On Tue, Nov 3, 2015 at 8:32 AM, 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.
> 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
> 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
> potential sources of entropy, along with SHA1, are in other packages.
> Opinions, ideas?
This snagged my interest so I had a poke around, from which maybe
getrandom() seems a better choice   - if available. Linux
earlier than Oct-2014 may not have it, and on OpenBSD and (maybe)
FreeBSD it is getentropy() .
Also I found discussion  interesting about mixing additional
entropy with OS supplied randomness, and discussion  is a very
interesting method that might provide that -- but is it worth the
additional effort ?
More information about the Vm-dev