[squeak-dev] Seeding instances of Random

Tobias Pape Das.Linux at gmx.de
Wed Nov 4 17:11:11 UTC 2015


On 04.11.2015, at 17:55, Ben Coman <btc at openinworld.com> wrote:

> 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"

Yes. but there's more platforms than Linux to care about :)
How'd we do it on, say, RiscOS or FreeBSD?

Best regards
	-Tobias

PS: FreeBSD is not hypothetical, we've got a student working with Squeak on FreeBSD…



More information about the Squeak-dev mailing list