[squeak-dev] Seeding instances of Random

Ben Coman btc at openinworld.com
Wed Nov 4 16:55:06 UTC 2015


On Wed, Nov 4, 2015 at 1:38 AM, Colin Putney <colin at wiresong.com> 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?
>
> 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?

If I properly understood my recent reading on this, every time you
take a number from a True-RNG, you reduce its entropy pool, which may
only refill slowly on a remote server.

>From http://linux.die.net/man/4/urandom ...
"The kernel random-number generator is designed to produce a small
amount of high-quality seed material to seed a cryptographic
pseudo-random number generator (CPRNG). It is designed for security,
not speed, and is poorly suited to generating large amounts of random
data. Users should be very economical in the amount of seed material
that they read from /dev/urandom (and /dev/random); unnecessarily
reading large quantities of data from this device will have a negative
impact on other users of the device"

cheers -ben


More information about the Squeak-dev mailing list