(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 <robert.w.withers@gmail.com> 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
Cryptography@lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography