Bill Sommerfeld writes:

...

the second 32bit seed is the "tick count", which I'm told is the number of milliseconds since windows started.

A 32-bit ms-resolution counter wraps roughly every 50 days. Very few Windoze PC's stay up that long :-).

Also (and note that it's been a while since I've messed around with PC's, but since the "architecture" remains chained to an early-80's design I suspect they're still the same) the PC clock frequency is generally pretty low. PC UNIX implementations usually run it at about 100 Hz, I think. There aren't a lot of available timers on the PC. One of them used to be used as the DRAM refresh timer; I don't know whether they still do that. On the other hand, getting at a Windows PC over the network is a whole 'nuther enchilada, though if I want to keep my day job I need to get that figured out real soon now. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A couple comments on using the time as a seed: Any system running NTP will let you know its clock to within a couple ms; some folks have gotten NTP accuracy down to the high hundred microseconds on real-time systems.. Any entropy you get from sampling the system clock will have to come from the low-order bits of the tv_usec, or equivalent, and you'll only get a few bits per sample. Getting real entropy from mouse movements under X may be tricky, because the X server goes out of its way to compress mouse movement reporting and to buffer events sent to the client ("X is an exercise in avoiding system calls"). You'll probably get less entropy than you might think.

the second 32bit seed is the "tick count", which I'm told is the number of milliseconds since windows started.

A 32-bit ms-resolution counter wraps roughly every 50 days. Very few Windoze PC's stay up that long :-). In a long-term active attack, the tick count can be estimated by periodically pinging the system under attack, noticing when it goes off the air and then back on again, and using that as a base value for the tick count search, so the tick count probably only adds a factor of somewhat less than 2**10 to the keyspace, not 2**32.. - Bill

Ed Carp writes:

Also add that many people seem to tend to swirl the mouse in fast circles, where there isn't *any* latency between mouse movements, and you get even less entropy. I suspect that Colin Plumb's code, while a nice try, would be a bit less useful that might have been otherwise suspected.

Colin's code, independent of implementation, simply uses MD5 as a block cipher to "launder" bit-streams that contain non-uniform distributions of true random data. See "Truly Random Numbers" in Dr. Dobb's Journal, November 1994, p. 113. How much entropy you get out depends entirely on what you feed in. I've put my code up on the cypherpunks ftp site, but I'm still waiting to hear back from the site maintainers as to its final location. In any case, that code uses the mouse _position_ and system timings in microseconds as input to the MD5 engine. So swirling the mouse should provide a good source of random input, better the faster it's moved. However, any code that generates random session keys should properly include routines to estimate the amount of entropy collected, and not generate a 128-bit key until at least 128 bits of entropy have been fed into the pool. This is a non-trivial problem, although PGP makes a good stab at it. To my knowledge, CryptDisk does not include this feature, and really ought to. For my own purposes in Curve Encrypt, this is not necessary, since I don't generate session keys, only salts. -- Will

In servalan.mailinglist.cypherpunks you write:

A couple comments on using the time as a seed:

Any system running NTP will let you know its clock to within a couple ms; some folks have gotten NTP accuracy down to the high hundred microseconds on real-time systems..

Yeah, and even if it's not running ntp full time (just doing the ntpdate hack in cron), with any justice it's still within a second of real honest-to-goodness WWV-and-friends time.

Any entropy you get from sampling the system clock will have to come from the low-order bits of the tv_usec, or equivalent, and you'll only get a few bits per sample.

Maybe not even that; does anybody know which of the popular machines actually have microsecond timers, so that gettimeofday() actually returns continuously updated microsecond values in between clock ticks? If you don't have that, your entropy in those low order bits is definitely gonna be pretty slim, since you're basically measuring the entropy in the "drift" values ntpd is applying, which don't change very quickly. I know BSDI actually uses one of the peecee timer registers to implement a microsecond timer, so you actually get decent time resolution; dunno if the other peecee *BSD releases do the same.