`Random' seed.

Vaporware which I heard around CFP '95, and have been sort of wondering about
ever since...

Some one told me that some one else [possibly Matt Blaze] had been looking
at how much randomness could be got by forking two child processes which
would just run as asynchronous clocks: whenever the parent program needs a
little `random' bit, it queries both and gives (clock(A) + clock(B) % 2)
or something.

Questions about this [to the list]:
 * who has done any [the?] work on this?
 * was it found to be useful/good or not?
 * what would be the drawbacks to adding this [Yet Another Source Of Entropy]
   to the Netscape scheme?

frodo =)

-- 
Richard Martin 
Alias|Wavefront - Toronto Office [Co-op Software Developer, Games Team]
rmartin@aw.sgi.com/g4frodo@cdf.toronto.edu      http://www.io.org/~samwise
Trinity College UofT ChemPhysCompSci 9T7+PEY=9T8 Shad Valley Waterloo 1992

Rick Busdiecker writes:
 > FWIW, I discussed this code briefly with an engineer at Netscape a
 > while back . . . .

 > 	signal(SIGALRM,printbit);
 > 	alarm(1);
 > 	while (1)
 > 		count++;

I for one would be a little peeved if I found that my browser was
consuming all available CPU bandwidth on my workstation.  I also have
some doubts as to the randomness of this; I suspect that the kernel is
rather deterministic in its scheduling practices.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Rick Busdiecker writes:
 > I don't think that anyone has suggested otherwise.  I believe that
 > `clock skew' was the underlying source of randomness that Matt Blaze
 > mentioned in the message where I first saw that code.

Yes, looking at Matt's code I think I believe it.

 > I have no idea how reasonable it would be to use this approach in
 > Netscape, however if it were available as an option to generate, say
 > 300 bits, I'd personally be plenty willing to let it chew up five
 > minutes while I get my morning caffeine.

If you look at it that way (the software just generates new bits every
once-in-a-while, like daily) I guess I wouldn't mind.  I mean, heck,
it's not like there aren't 3 dozen other random daemons that pop up
and eat my CPU every now and then :-)  It'd only really be a problem
if it were used as an "operational" source of random bits.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----BEGIN PGP SIGNED MESSAGE-----

    From: m5@dev.tivoli.com (Mike McNally)
    Date: Mon, 25 Sep 1995 07:29:01 -0500
    
    I also have some doubts as to the randomness of this; I suspect
    that the kernel is rather deterministic in its scheduling
    practices.

I don't think that anyone has suggested otherwise.  I believe that
`clock skew' was the underlying source of randomness that Matt Blaze
mentioned in the message where I first saw that code.

In any case, a number of people have expressed interest in seeing
signs of non-random behavior.  As far as I know, no one has said
anything if they've found such signs.  I've tried to find some, but
only with very simple tests.  I generated a quarter megabits and found
that:

 - I can only compress it to about 32Kb, i. e. 256 k bits.  Tim May
   has suggested that compressibility is getting to be a good metric
   for entropy.

 - It seems to contain roughly equal numbers of:
    * 0s and 1s
    * 00s, 01s, 10s, and 11s
    * etc. I forget how high I checked.

 - It contains some rather long sequences of 0s and 1s.  I think on
   the order of 20.

I have no idea how reasonable it would be to use this approach in
Netscape, however if it were available as an option to generate, say
300 bits, I'd personally be plenty willing to let it chew up five
minutes while I get my morning caffeine.  I realize that some people
would not.  It certainly couldn't hurt to throw a few bits gathered
this way into the mix.  Also, it may be possible to get more than one
bit of entropy per second using this approach, I was merely showing
the code as Matt originally presented it.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMGanppNR+/jb2ZlNAQE2jQQAx1dj/WjMK4XeNr4mZxyW6G9TKL1ZKqOE
tkePnuEujXQDxoEy5UNGWo36NG1hn564wprdS5e4aCQwZaPhPOuXZTd9uPEWXdqq
j5WyNmzBqmSIlCU+wlEVnBpYWbgxdPC1Lx8ckkxxX07+F3B+ftibrfB+t7ysDDPC
LOJ2PCXr/7I=
=8lGs
-----END PGP SIGNATURE-----
--
Rick Busdiecker                        Please do not send electronic junk mail!
 net: rfb@lehman.com or rfb@cmu.edu    PGP Public Key: 0xDBD9994D
 www: http://www.cs.cmu.edu/afs/cs.cmu.edu/user/rfb/http/home.html
 send mail, subject "send index" for mailbot info, "send pgp key" gets my key

-----BEGIN PGP SIGNED MESSAGE-----

    From: Richard Martin <rmartin@aw.sgi.com>
    Date: Wed, 20 Sep 1995 09:15:49 -0400

    Vaporware which I heard around CFP '95, and have been sort of
    wondering about ever since...

    Some one told me that some one else [possibly Matt Blaze] had been
    looking at how much randomness could be got by forking two child
    processes which would just run as asynchronous clocks: whenever
    the parent program needs a little `random' bit, it queries both
    and gives (clock(A) + clock(B) % 2) or something.

I've played around with something that Matt posted here a while back
which seems to use the same idea.  Matt suggested that this appears to
emit one random bit per second.  I've done some very lightweight
analysis and haven't seen anything to suggest that the output is not
random, but I wouldn't make any bets based on what I've done.

FWIW, I discussed this code briefly with an engineer at Netscape a
while back . . . .

			Rick

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
/* -*- Mode: C -*- */

/*********************************************************************

This is from a message on the Cypherpunks mailing list:

 Posted-Date: Fri, 20 Jan 95 03:36:17 -0500
 Message-Id: <9501200836.AA19977@merckx.info.att.com>
 To: cypherpunks@toad.com
 Subject: Re: Threats in real life - what are we worried about? 
 Date: Fri, 20 Jan 95 03:36:17 -0500
 From: Matt Blaze <mab@research.att.com>

*********************************************************************/

#include <stdio.h>
#include <signal.h>
int count=0;
void printbit()
{
	signal(SIGALRM,printbit);
	alarm(1);
	printf("%1d",count&01);
	fflush(stdout);
}
main()
{
	signal(SIGALRM,printbit);
	alarm(1);
	while (1)
		count++;
}

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMGXhPZNR+/jb2ZlNAQEkdgQAlVBgpN8LLeb9TM0dhy1Bx7KXfHCiIqV6
UoLRm/hoEzsiOnGbJeNlx2n1dyxdmti/Zvacnsi2CAKHhJGAaARcQGy+hWc6uS3v
nbOqOoFkvRlWYyYV6QLgvKckYM+tbYBvrjQgQ/XivpoPQPbzyRI6cW4soLuJ7fpu
xug5C8yYc8A=
=dT9a
-----END PGP SIGNATURE-----