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."