My Day

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.

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

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

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.