From: tcmay@got.net (Timothy C. May)
Date: Wed, 20 Sep 95 00:09:43 PDT
To: cypherpunks@toad.com
Subject: Re: netscape's response
Message-ID: <ac85072c28021004746c@[205.199.118.202]>
MIME-Version: 1.0
Content-Type: text/plain


At 5:53 AM 9/20/95, Jeff Weinstein wrote:

>  Of course none of this reduces the magnitude of the screw up/bug/design
>flaw/whatever.  I really can't say which of these it was since I wasn't
>around at the time that this code was being written.  I must admit that
>the RNG seed code was not an area that I thought to examine when I took
>over our security library.

In _retrospect_ (:-}), the approach taken by Goldberg and Wagner seems
pretty obvious. Where PGP, for example, asks the user to go through a
laborious process of "generating entropy" through ostensibly-random
keyboard button presses, Netscape does not do this. Nor does it, for
example, "listen" to a microphone input for some amount of time (to at
least make a plausible pretense of gathering entropy), nor does it measure
a Zener diode, or count clicks of a Geiger counter, or whatever.

The very speed of Netscape's PRNG process suggests the usual weakness in
PRNGs: simply not enough entropy. That is, a limited search space allows
the guessing of a seed or entry point in a deterministic process.


>  This was a bad mistake on our part, and we are working hard to fix it.
>We have been trying to identify sources of random bits on PCs, Macs, and
>all of the many unix platforms we support.  We are looking at stuff that
>is system dependent, user dependent, hardware dependent, random external
>sources such as the network and the user.  If anyone has specific
>suggestions I would love to hear them so that we can do a better job.

I think a reasonable way to generate several hundred seemingly random (or
at least highly unpredictable) bits is the "swirling the mouse" approach
mentioned by several people. All implementations of Netscape involve mice,
I assume, and this is a fairly fast way of generating hard-to-guess bits.
Colin Plumb has code to do this, as has been mentioned. (I'm not saying
that some number of "mouse swirlings" will generate some number of bits of
entropy...this depends on the platform, the granularity of mouse
measurements, etc. Better to take several times as many bits as needed and
distill them down, with MD5 or other hash functions....can't have too many
bits of entropy to start with!)

This could be done fairly quickly by Netscape, and doesn't assume the
platform has microphones to "measure background noise" or other exotic and
nonstandard inputs.

Years ago, I recall articles in sci.crypt about getting "pretty good random
numbers" from complicated measurements of disk accesses on a local machine,
ticks of the system clock, times between keyboard button presses, etc., all
mixed and convolved together. Not perfect, of course, but if enough bits
are started with (e.g, 2000) when "only" 126 or 512 or whatever are
ultimately used, this "mixing" can probably be pretty damned good. At
least, I doubt any t-shirts will be won.


>  Do you mean that cypherpunks offered to review the netscape code
>if only we made all the source available on the net?  I think that it
>is unrealistic to expect us to release all of our source code to the
>net.
>
>  We will be having at least some of our code reviewed by a
>wider audience, but I don't yet know which code, or how wide a review
>group.  If anyone has specific suggestions for pieces of code that
>you would like to see widely reviewed (such as RNG and seed generation)
>let me know.
>
>  I realize that some cypherpunks think that we should make all of
>our code publicly available.  In an ideal world that would be great,
>but we live in a world with politicians, crooks, lawyers, stockholders,
>etc...  Don't expect to see us posting our entire security
>library source code to cypherpunks.

I think a better approach is to modularize the functions, so that a "PRNG"
chunk could be shown without "damaging" Netscape's market situation. (I
doubt the crypto section is seen as Netscape's market edge, and use of
industry-verified crypto modules would be a net plus, anyway.)

In other words, keep secret (arguably) the things you don't want
competitors to have access to. But things like crypto modules are rarely
trade secrets--if only because the cores are so often licensed anyway--and
can be shown and vetted without affecting the rest of the product.

(I said "arguably" because many will argue for showing all of the source
code, anyway, as the almost-ultimate check on integrity and reliabilty. And
there may be subtle security flaws that hinge on the overall program, not
just specific parts.)


>  I would love to hear your suggestions for good sources of entropy
>on any systems that our products run on.

See above. This has been a recurring topic in sci.crypt and Cyherpunks---so
recurring, in fact, that several of us have expressed bemusement at seeing
"yet another "How do I generate entropy" argument."

I guess we all (save for Mssrs. Goldberg and Wagner) tacitly assumed that a
modern product claiming to have strong crypto would use commonly-accepted
techniques for generating enough entropy. (Commonly used in RSA's crypto
products, and in PGP.)

I suggest you take RSADSI up on their offer to advise you. (Or Cylink, as
the case may soon be.)

--Tim May

---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."