[squeak-dev] Seeding instances of Random
Levente Uzonyi
leves at elte.hu
Tue Nov 3 00:32:52 UTC 2015
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.
Opinions, ideas?
Levente
More information about the Squeak-dev
mailing list
|