Random is not random at startup

(Hey Rob, long time no Smalltalk!)

I suggest some changes we did in Cuis. First, for Park-Miller you can do a small change to #initialize, insert a hashMultiply somewhere when initializing the seed. I did experiments in Cuis, drawing histograms to see if it looks like a uniform distribution, and ended up doing something like

  seed _ (Time millisecondClockValue + self identityHash) hashMultiply \\ m

Another issue with Random that we addressed in Cuis is related to the bit size of each output. Random>>nextValue returns Floats with 31 random bits (or 30). It doesn't return a uniformly distributed Float between 0 and 1 (some Float values don't have a chance to be output). Similarly, Random>>nextInt: n will not really return an integer between 1 and n if n is large enough, for example (1 << 64) atRandom returns always odd integers (not very random uh).

So I suggest to think of Random as a generator of random "bits" or "blocks of bits", and to generate a Float it should actually build it from 52 randomly generated bits (to fill out the mantissa), and nextInt: n should also be implemented from random bits (or chunks of bits).

On Wed, May 18, 2016 at 11:25 PM, Robert Withers <[hidden email]> wrote:

Thanks for cc-ing me. I don't have much exposure to random, so I am cc-ing the Cryptography list, in hopes they might help. This doesn't very random, you're right. Here were Peter's questions:

My questions:

1) do we really want to have global fixed seed?

2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value

3) Should we switch to what UUIDGenerator is using… reading /dev/urandom for the initial seed setup?

Rob

On 05/18/2016 07:05 PM, Peter Uhnák wrote:

Hi,

(cc-ing Robert Withers as he seems to be working with cryptography and security... as this seems related and may have some implications, but I am likely wrong about the implications)

yesterday I've encountered a very surprising behavior

I executed the same script `10 atRandom` on the same image without saving it and got the same output:

while true; do

        pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom'

done

10

10

10

10

10

10

Not so random… not random at all.

Apparently the default random generator uses SharedRandom pool, that is initialized only once… so every time you start an image you get the EXACT same random seed... I think this is stupid, and I am not sure what are the security implications of this (e.g. when opening an SSL connection… having fixed world-wide initial seed seems like an awful, awful idea), but whatever…

So instead I tried to explicitly specify the Random generator… which I can do

while true; do

        pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: Random new'

done

5

5

5

5

5

Still not random… what?

while true; do

        pharo-vm --nodisplay latest.image --no-default-preferences eval 'Random new instVarNamed: #seed'

done

426306047

426305545

426305546

426306010

So the seed is different but thanks to the magic of masking the seed, I always get the same first several bits… thus the same result for small numbers.

So if I actually want what seems like a random value… I have to at least once run the generator…

while true; do

        pharo-vm --nodisplay latest.image --no-default-preferences eval '10 atRandom: (Random new next; yourself)'

done

7

3

4

9

6

7

Once I start to use it the properties of the algo kick in so it's pseudo-random… but I need to run it once to initialize it, which is wtf.

My questions:

1) do we really want to have global fixed seed?

2) Random new should actually setup a usable seed so I don't need to first run it N times before I can use the value

3) Should we switch to what UUIDGenerator is using… reading /dev/urandom for the initial seed setup?

Peter

_______________________________________________
Cryptography mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography