Re: "random" number seeds vs. Netscape

[Phil Karlton <karlton@netscape.com>]

Perry E. Metzger wrote:
> This is true. However, you must get 128 bits of entropy into the MD5
> -- this can be accompanied by as much junk as you like, but if there
> are at least 128 bits of entropy fed in, the MD5 process will distil
> it into what you want.

My assumption ws that if we conservatively counted at least 300 bits of entropy,
we would have 128 for sure. Not very scientific, 

> You might want to read RFC 1750,

Did that. It talks about a lot of the pitfalls. Unfortunately it does not address
(nor can it realistically be expected to address) details of what to look for
on a particular version of an OS running on some particular platform.

> and examine the code PGP uses for
> doing its random generation. Clients do lots of fairly random things
> while talking to netscape (click and keyboard press times, etc) that
> can be incorporated in, along with other sources of bits. You should
> grab bits whereever you can and keep them for when you need them, as
> getting 128 bits takes a while.

Gee, I thought I pointed out that we were putting that code in as part of
the going idle.

> PC timers inherently run at Mhz speed -- they interrupt every 100th of
> a second but you can get finer resolution by querying the clock
> chip. Does Windows let you do this?

I don't know, but I'll forward this on to our PC guys. It might be a portability
problem.

> I wouldn't do that, since it forces you to have a dependancy on
> executing a subprocess.

We try to be careful about dealing with the subprocess failing to run.

> Were I you, I'd capture the timer on every single keystroke and mouse
> click event and feed that in to your entropy generator a la PGP.

We are constantly trying to improve this area of our code. We are still taking
suggestions.

By the way, the security engineers are doing what we can to make sure that we
can expose as much of the seed generation algorithms as possible. There is a
chance we can get permission to post the code.

> >       System specific info such as hardware serial number or
> >       system id.

> By definition, that isn't random. Don't use it.

It doesn't hurt. It's also information that is not available to the external
evesdropper. Other than execution time, why should I remove it from the list
of bits being fed into the hash? Successfully getting this information probably
involves physical access to the machine.

> There are other things you can mix in, besides keystroke and mouse
> timings and positions, like system call timings for things that might
> take a bit of time.

We will check this one out also. For the really low resolution clocks, the
answer will be zero most of the time. :-)

> >     Multi-user Unix machines present a special problem. There are those
> >     at Netscape that argue that anybody who has login access to your
> >     machine may as well be considered to have root access. There are
> >     enough known attacks that this is true to a large extent.  However,
> >     I think we can do better than just giving up.
> 
> I agree. Don't run on the assumption that everyone has root --
> otherwise you'll build something that produces less safety than it could.

I agree, but I have a hard arguing with those that asser that the security
of UNIX is weak enough that given what we are doing for the patch it will
be easier to become root from a logged in account than to hack the seed.

PK
--
Philip L. Karlton			karlton@netscape.com
Principal Curmudgeon			http://www.netscape.com/people/karlton
Netscape Communications Corporation