James, I thought about using crypt as well, but decided that it wasn't really the random number generator (or crypt) that was the problem, but the initial seed. I.E. the possible end result is still dependant on the resolution of the clock. Now given that a certain function (crypt in this example) won't take the exact same amount of time, it might work. That is where the resolution of the timer comes in. If the timer resolution is so bad that the time for crypt to run can be predicted within the accuracy of the clock, then it's no good. Even if someone could calculate 100 possible values for the time difference, then it's still not good enough. You could loop that n times, and end up with 100^n possible values, but I'm sure there would be other ways to narrow down the possibilities (i.e. subsequent calls to crypt are going to be very close in timing to other recent calls to crypt due to a similar load on the system at that time). You do have a good idea about the conditions though, I'm not sure if the crypt call helps though. Crypt just produces a different values based on it's input, but given the same imput, it creates the same value. In this application, it doesn't matter WHAT the value is, just how many possibilities it has, and the number of possibile outputs of crypt is the number of possible inputs you give it. For example, if tv_usec can only have 100 possible values (100ths of a second as Perry suggested), then you've only got 200 possible outcomes. Obviously the more you loop it, the more possible outcomes, but it should be possible to predict approximatly how long each loop takes to run. If the loop runs too quickly to get an accurate prediction, then it's faster than the system clock anyway and you'll end up with a predictable (same) value for tv_usec. Can random be back-traced? I mean, can a value returned by random be used to find the initial seed? If so, then I guess crypt would be a much better idea. What do you think of something like this: seed = timer do seed = seed * timer while !(seed % 100) I'm just wondering if the gettimeofday call inside the loop will introduce enough randomness or not? I'm also not sure about the probabilities surrouding multiplication. I.E., if seed is initially even, then it will be even regardless of what timer is. You mentioned xoring though, thats a great idea, that should help a lot because any bit of the output of xor can't be determined without knowing BOTH input bits. I also can have the program wait for the user to press enter. That's the concept pgp uses to generate it's random number, you have to type 100 keys or so and it measures the timing between your keystrokes for the seed. I just don't want someone to have to press a key 100 times before it will output the result (since we will be using it a lot). I'll go change my * to s - Thanks, Rick On Wed, 30 Apr 1997, Graham, James wrote: > You _could_ do a random number generator triggered by cycling stuff > through > the crypt() call once, converting from the base-64 string into binary, > then > using that number to seed your generator. > > There's an AWFUL lot of possibility there, especially if you grab > tv_usec, > even if there are a limited number of possible values. > > Picture this one: > > grab tv_usec; > translate to ascii; > run thru crypt(); > translate result from base-64 to binary; > grab tv_usec again; > even-result: run thru compression > odd-result: run thru ebcdic encoding > convert result to a binary number; > seed your generator. > > Convoluted, but if you throw several layers of uncertainty in there > (maybe repeat several times of grabbing the tv_usec, filtering it > thru crypt(), xoring the value and running it thru crypt() again), > especially ones which have more than one possible return value, > you have a pretty-close-to-perfect implementation. > > It would be really cool, but not strictly necessary, to have a > random number generator in the kernel. > > /* note for crypt(): I mean the DES crypt or other routine > which does a ratio of input:output better than 1:1024 */ > > Reply-To: greywolf@starwolf.com > > This message made possible by > Microsoft > "I'VE GOT A BAD FEELING ABOUT THIS" > ========================================================================= Rick Byers Internet Access Worldwide rickb@iaw.on.ca System Administrator Welland, Ontario, Canada (905)714-1400 http://www.iaw.on.ca/rickb/ http://www.iaw.on.ca/