[Vm-dev] Re: [squeak-dev] Seeding instances of Random

Ben Coman 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.
> 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
> potential sources of entropy, along with SHA1, are in other packages.
> Opinions, ideas?
> Levente

This snagged my interest so I had a poke around, from which maybe
getrandom() seems a better choice [1] [2] - if available.  Linux
earlier than Oct-2014 may not have it, and on OpenBSD and (maybe)
FreeBSD it is getentropy() [3].

[1] http://djalil.chafai.net/blog/2014/10/13/linux-kernel-3-17/
[2] http://man7.org/linux/man-pages/man2/getrandom.2.html
[3] http://www.2uo.de/myths-about-urandom/

Also I found discussion [4] interesting about mixing additional
entropy with OS supplied randomness, and discussion [5] is a very
interesting method that might provide that -- but is it worth the
additional effort ?

[4] http://security.stackexchange.com/questions/43344/open-source-alternative-for-cryptgenrandom
[5] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html

cheers -ben

More information about the Vm-dev mailing list