Netscape "random" number seed generator code available
Once again I speak for myself and not Netscape. The random number seed generation code is now available for review: ftp://ftp1.netscape.com/pub/review/RNGsrc.tar.Z The README from that file is appended below. Netscape has fixed other less glaring but potentially interesting problems and those fixes will be included with the patch that goes out in the near future. As is mentioned in the README, more will need to be done to find more bits of entropy. (Too much of a good thing is still not enough.) However the security team believes that the RNG seed is no longer the weak link and candidate for attack. So I am personally volunteering to have my had shaved if a discovered deficiency in this code results in an easily attacked generated seed. [You will be expected to show your work. :-)] ============================== README =========================== This code represents the heart of Netscape's random number seed generator. The initialization routines are called by the various client front ends and servers and other Netscape software. Furthermore, the server will be putting seed information into the environment of each of the CGI invocations. Here's some things a client does: * Application specific files are passed to SEC_FileForRNG(). For the client this includes the global history file. * The clients then read a portion of the screen depending upon the current state of the hash. * The Update functions feed into an MD5 hash. The MD5 code isn't ours to publish. * User input is used for server side key generation and in client front ends for increasing RNG state entropy over time. This code needs to be portable. We can't access device specific registers that are not guaranteed to be on all relevant platforms. Recommendations to users of Netscape who rely on the security of their transactions: If the attacker has physical access to your machine, security cannot be assured. Netscape continues to point out that if unwanted agents can log into your machine, little can be secure. For secure servers, any insecure connection mechanism could be suspect. Multi-user UNIX platforms will not be as secure as single-user machines. Details: Some of the system specific information that is used in the seed generation is available to any user on that system. To help mitigate this, the entire user environment is passed into the seed generation algorithm. A wary user can alter his user environment before running Netscape software. If someone can get root (superuser) access to your machine, they can pretty much do anything. Netscape security could be weak if run on a platform emulator. Use a version native to the platform on which you are running. Details: Some of the usefulness of the seed generation depends upon the unpredictability of the low order bits of various clocks and timers. The clocks of many emulators may have much less entropy than the actual builtin clocks. If you are running on a UNIX platform, make sure of the security of your X server. This is also true if the X connection is not to a local machine as all of the events and the data from the screen read may be captured from the ethernet. Details: If the attacker is monitoring your user input then its randomness is not useful. It is better to perform some user action before connecting to a secure site. This means you should not set your home page to a secure site or launch your client from a command line to a secure site. Details: While navigating through menus or typing into various form fields, the Navigator uses the unpredictability of details of the user actions to increase the entropy of the RNG state. For this patch, proposed changes had to fit into the existing code and UI structure. We will rely on the user interactions leading to the initial secure page. In future versions, the Navigator will force the user to explicitly use the keyboard or mouse to help generate the initial seed before doing any secure transactions. That seed will be maintained across invocations of the Navigator. The files are not compilable as is. They have been extracted from the Netscape's cross platform build environment, and all of the headers needed to compile them are not included. They should be compilable with some simple edits on their platforms (MFC on Windows, CodeWarrior on Mac). ================================================================= PK -- -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://www.netscape.com/people/karlton Netscape Communications Corporation
On Sep 25, 2:38, Phil Karlton sent the following to the NSA's mail archives:
Subject: Netscape "random" number seed generator code available || As is mentioned in the README, more will need to be done to find more || bits of entropy. (Too much of a good thing is still not enough.) || However the security team believes that the RNG seed is no longer the || weak link and candidate for attack. So I am personally volunteering || to have my had shaved if a discovered deficiency in this code results || in an easily attacked generated seed. [You will be expected to show || your work. :-)] ||
Will you put a picture up on http://www.netscape.com/ someone does find a problem? 8-) -- ========================================================================== David J. Bianco | Web Wonders, Online Oddities, Cool Stuff iTribe, Inc. | Phone: (804) 446-9060 Fax: (804) 446-9061 Suite 1700, World Trade Center | email: <bianco@itribe.net> Norfolk, VA 23510 | URL : http://www.itribe.net/~bianco/
In article <199509251256.IAA27310@gatekeeper.itribe.net>, bianco@itribe.net (David J. Bianco) writes:
On Sep 25, 2:38, Phil Karlton sent the following to the NSA's mail archives:
Subject: Netscape "random" number seed generator code available || As is mentioned in the README, more will need to be done to find more || bits of entropy. (Too much of a good thing is still not enough.) || However the security team believes that the RNG seed is no longer the || weak link and candidate for attack. So I am personally volunteering || to have my had shaved if a discovered deficiency in this code results || in an easily attacked generated seed. [You will be expected to show || your work. :-)] ||
Will you put a picture up on http://www.netscape.com/ someone does find a problem? 8-)
I will make sure that a picture is available on the web if Phil has to shave his head. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Will you put a picture up on http://www.netscape.com/ someone does find a problem?
If you look at my home page (see below), you can see a picture from about 25 years ago. If I have to shave my head, I will post before and after pictures. PK -- Philip L. Karlton karlton@netscape.com Principal Curmudgeon http://www.netscape.com/people/karlton Netscape Communications Corporation
In article <4454nu$da8@tera.mcom.com>, karlton@neon.netscape.com (Phil Karlton) writes:
Details: While navigating through menus or typing into various form fields, the Navigator uses the unpredictability of details of the user actions to increase the entropy of the RNG state.
Note that clicking in the main window or on URLs, and timing of network activity cause the state of the RNG to be updated. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
More on the RNG stuff. On Unix systems we look for ~/.pgp/randseed.bin, and feed it through the RNG hash. On Unix and PC systems we feed the environment through the hash, so that would be a good place for a concerned user to put some random stuff of their own. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Jeff Weinstein wrote: | | More on the RNG stuff. On Unix systems we look for ~/.pgp/randseed.bin, | and feed it through the RNG hash. On Unix and PC systems we feed the | environment through the hash, so that would be a good place for a | concerned user to put some random stuff of their own. On a SunOS (or any BSD) box ps -e will get you environment variables. ps -eaxuw USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND root 53 0.0 0.0 68 0 ? IW Sep 19 0:02 portmap HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb root 68 0.0 0.0 16 0 ? I Sep 19 0:00 (biod) root 58 0.0 0.0 40 0 ? IW Sep 19 0:00 keyserv HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
jsw@neon.netscape.com (Jeff Weinstein) writes: More on the RNG stuff. On Unix systems we look for ~/.pgp/randseed.bin, and feed it through the RNG hash. On Unix and PC systems we feed the environment through the hash, so that would be a good place for a concerned user to put some random stuff of their own.
Interesting idea, but I have a (perhaps irrational) dislike for this idea. If Netscape wants to have its own netsceed.bin file to muck around with on my system, I'll authorize it to be set up, but I by god don't want it mucking around with my PGP setup. Network-aware programs must be more trusted than local-only programs, because they are the only kind that legitimately export information they glean from the local environment. If Netscape decided to ship the actual contents of my randseed.bin to somebody else (like escrow.fbi.org, for example) it might give them else a better edge on finding session keys for my PGP sessions... the privacy of which I value more even than I value my Netscape transactions. I'm nervous enough about all the Easter Eggs that have been reported in Netscape, like the secret keystroke shortcut to get to Fishcam, or the different behavior it exhibits when it finds a certain obscurely-named directory at the top level. If it starts peeking at my PGP environment, though, I'm drawing the line. No, thanks. In summary -- set up your own netsceed.bin if you want, but don't peek at my PGP randomness. Jim Gillogly Trewesday, 4 Winterfilth S.R. 1995, 11:57
On Mon, 25 Sep 1995, Jim Gillogly wrote:
jsw@neon.netscape.com (Jeff Weinstein) writes: More on the RNG stuff. On Unix systems we look for ~/.pgp/randseed.bin, and feed it through the RNG hash.
Interesting idea, but I have a (perhaps irrational) dislike for this idea. If Netscape wants to have its own netsceed.bin file to muck around with on my system, I'll authorize it to be set up, but I by god don't want it mucking around with my PGP setup. ...
I thought about this a bit, but I don't think that reading randseed.bin counts as "mucking around with" the "PGP setup." PGP launders randseed.bin before saving it for just this reason, so that reading it won't reveal information on the user's session keys. And the Netscape folks have published the source code which shows that they only read the file and hash it with MD5. That the contents of randseed.bin have been mixed into an MD5 hash with a bunch of other things can hardly be called a security hole, in my estimation. David R. Conrad, conrad@detroit.freenet.org, http://www.grfn.org/~conrad Hardware & Software Committee -- Finger conrad@grfn.org for public key Key fingerprint = 33 12 BC 77 48 81 99 A5 D8 9C 43 16 3C 37 0B 50 No, his mind is not for rent to any god or government.
Jeff Weinstein writes:
More on the RNG stuff. On Unix systems we look for ~/.pgp/randseed.bin, and feed it through the RNG hash.
You should search for the PGPPATH environment variable rather than making assumptions about where it is...
On Unix and PC systems we feed the environment through the hash, so that would be a good place for a concerned user to put some random stuff of their own.
Not a bad idea, but not a substitute for extracting enough bits of entropy on your own... Perry
jsw@neon.netscape.com said:
More on the RNG stuff. On Unix systems we look for ~/.pgp/ randseed.bin, and feed it through the RNG hash. On Unix and PC systems we feed the environment through the hash, so that would be a good place for a concerned user to put some random stuff of their own.
For UNIX, including the environment is pretty useless for determining a seed. On BSD-style machines, try a ps -uxeww. The environment is known by anyone who has access to the machine when the seed is generated, and possibly to many others, since some machines have SNMP daemons that will give out the process table, or may have the systat "service" turned on. The later two may not include the environment on most machines, but I believe it concievably could, and may be implimentation specific from UNIX to UNIX. I greatly applaud Netscape for "going public" with this information, and remaining open to suggestions despite the bad publicity it has been getting. One of the large corporations I work with is looking to do an electronic commerce with some pretty amazing $ amounts soon (at least, amazing to me), and I know I'm going to be asked about the security breaks. I feel confident that I can tell them exactly what is wrong, and what Netscape is doing to fix it, and that I don't think it should be a matter for great concern. I'm not sure I could have done that had Netscape done nothing but issue the press release and weather the bad press in silence. Bob
adam@lighthouse.homeport.org (Adam Shostack) wrote:
Jeff Weinstein wrote: | | More on the RNG stuff. On Unix systems we look for ~/.pgp/randseed.bin, | and feed it through the RNG hash. On Unix and PC systems we feed the | environment through the hash, so that would be a good place for a | concerned user to put some random stuff of their own.
On a SunOS (or any BSD) box ps -e will get you environment variables.
ps -eaxuw USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND root 53 0.0 0.0 68 0 ? IW Sep 19 0:02 portmap HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb root 68 0.0 0.0 16 0 ? I Sep 19 0:00 (biod) root 58 0.0 0.0 40 0 ? IW Sep 19 0:00 keyserv HOME=/ PATH=/bin:/usr/bin:/usr/etc:/usr/ucb
If you take a look at the code you will see that this (and a ton of other things) are already being done...Jeff is only pointing out an extra item which is of special interest to the people in this group...we are no longer relying on any single item of data but rather a very large set and constant re-seeding during idle loops... -Jon
participants (10)
-
Adam Shostack -
Bob Snyder -
David J. Bianco -
David R. Conrad -
Jim Gillogly -
Jon Mittelhauser -
jsw@neon.netscape.com -
karlton@neon.netscape.com -
Perry E. Metzger -
Phil Karlton