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-----
participants (3)
-
m5＠dev.tivoli.com -
Richard Martin -
Rick Busdiecker