[Cryptography Team] Re: Random is not random at startup

[Luciano Notarfrancesco]

(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 at 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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/cryptography/attachments/20160521/48863078/attachment.htm