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/re... <http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573/re...> &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