Well, my brain's pretty frazzled about now (and I still have a pretty dense paper on xFS to read and summarize for 9am tomorrow for my OS class) from all the press that's gone after me today. The ones I wrote down (I believe sameer wanted a list; I have names and numbers for some of these, too, bt it was pretty hectic: get off the phone, go to my terminal, note that I have 20 new mail messages from people wanting interviews or info, and answer the phone because it's ringing again.): NY Times WS Journal SF Chronicle CNN (camera crew) Marketplace (NPR) SF Examiner Kansas City Star Chronicle of Higher Education Boston Globe Newsweek (or WiReD; it was Steven Levy) and at least half a dozen more. Not to mention the job offers, one call that I couldn't decipher (it sounded like one of those AI's that you see roaming the net every so often, only on the phone), and email in French (je suis canadien, but I was still amazed I could understand it). Sorry for the blathering, but that's how I feel just now. BTW: the line we tended to stress was "public availability of source to at least the security bits", but who knows how it will come out? Holger.Reif@PrakInf.TU-Ilmenau.DE (Holger Reif ) was kind enough to verify that the SunOS 4.1.3 version of Netscape generates its keys in _exactly_ the same way as Solaris and HP-UX; he says he'll test other architectures tomorrow. I suspect any big-endian machine with the lrand48() function (which is used in key generation on Solaris/HP-UX; it's disguised in unssl.c as the macro mklcpr()) will be the same. Other Unix flavours should require only minor changes. I'm still interested in what Windoze clients do (other than lose). - Ian "So how _did_ Netscape's stock do today?"
In article <43o44t$hof@calum.csclub.uwaterloo.ca>, iagoldbe@calum.csclub.uwaterloo.ca (Ian Goldberg) writes: [ summary of Ian's day deleted ] Now imagine what my last 48 hours have been like. :-)
Holger.Reif@PrakInf.TU-Ilmenau.DE (Holger Reif ) was kind enough to verify that the SunOS 4.1.3 version of Netscape generates its keys in _exactly_ the same way as Solaris and HP-UX; he says he'll test other architectures tomorrow. I suspect any big-endian machine with the lrand48() function (which is used in key generation on Solaris/HP-UX; it's disguised in unssl.c as the macro mklcpr()) will be the same. Other Unix flavours should require only minor changes.
Most of the unix machines do the same thing. On SGI machines that have the hardware cycle counter, its value is used in place of the srand48(usec), lrand48() sequence. BSDI the code used srandom and random.
I'm still interested in what Windoze clients do (other than lose).
On windows and mac the first 32bit seed is seconds since 1970, and the second 32bit seed is the "tick count", which I'm told is the number of milliseconds since windows started. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike McNally writes:
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.
No, it isn't actually. You can get a microsecond timer out of it. The clock interrupts occur only infrequently, but the clock chip itself increments very very fast, and if you wanted microsecond timings of keystrokes there are registers that will give you what you want. Perry
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
-----BEGIN PGP SIGNED MESSAGE-----
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.
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. - -- Ed Carp, N7EKG Ed.Carp@linux.org, ecarp@netcom.com 214/993-3935 voicemail/pager Finger ecarp@netcom.com for PGP 2.5 public key an88744@anon.penet.fi Q. What's the trouble with writing an MS-DOS program to emulate Clinton? A. Figuring out what to do with the other 639K of memory. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMGAhFSS9AwzY9LDxAQF/oAP/TrE912Sy8DqTG2oQQ3bgK//5bPGmoX1h cVS4uwSrSJ+wdkkvExZV1I3eqkQCJEkZjsJp83ZtOD44nxOd9aDiY+XuarVU8UDW f/9oPtYCjDU2MPD+Tu4ftL9I5B0WqT+V/4RAkvwPdqNnzqgNiCTIdPwEOHp+gNl2 Cv3/3e6/Bh4= =pvSP -----END PGP SIGNATURE-----
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
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.
Did you send mail to cypherpunks-ftp@csua.berkeley.edu ? /pub/cypherpunks/randomness -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 An Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer@c2.org
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.
participants (9)
-
Bill Sommerfeld -
Ed Carp [khijol SysAdmin] -
iagoldbe@csclub.uwaterloo.ca -
jsw@neon.netscape.com -
m5@dev.tivoli.com -
Perry E. Metzger -
rmtodd@servalan.servalan.com -
sameer -
W. Kinney