Hi Peter,

You are absolutely correct.�� There is a lot that can be done to improve gathering entropy on cryptography.�� We have discussed this a number of times.

At 3DICC use the croquet plugin and #gatherEntropy: by Andreas.�� That works great for us.�� We have very specific random needs including replicated randoms.

it uses

/dev/urandom on linux and MacOS and

SystemFunction036 in Advapi32.dll on windows

In general you hit on the issue. ��We should have an implementation for #gatherEntropy: in crypto.�� It should fire off for seeding PRNG during startup, The makeSeed in UUIDGenerator seems insufficient unless you are on linux.��

It queries the sound system and then defaults to a time calculation.�� How good that is for you really depends on your specific needs for random.

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

[Ron Teitelbaum] No

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

[Ron Teitelbaum] Yes it should call gatherEntropy to seed the PRNG

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

[Ron Teitelbaum] No we should either implement a proper gatherEntropy method or use SystemFunction036 in Advapi32.dll for windows like we do in CroquetPlugin.�� Chris previously pointed out the gatherEntropy requirements from http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573/ref=sr_1_1?ie=UTF8&qid=1385152889&sr=8-1&keywords=schneier+practical+cryptography that would be a good place to start or we should support the croquet plugin method gatherEntropy in cryptography.

All the best,

Ron Teitelbaum

From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Robert Withers
Sent: Wednesday, May 18, 2016 7:26 PM
To: Peter Uhn��k; Pharo Development List; Cryptography Mailing List
Subject: Re: [Pharo-dev] Random is not random at startup

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