[squeak-dev] Seeding instances of Random

Ben Coman btc at openinworld.com
Thu Nov 5 13:33:19 UTC 2015


On Thu, Nov 5, 2015 at 1:11 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> 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…
>

FreeBSD has /dev/urandom as shown in the table a few pages down here...
http://insanecoding.blogspot.com.au/2014/05/a-good-idea-with-bad-usage-devurandom.html

I don't know about RiscOS.
cheers -ben


More information about the Squeak-dev mailing list