NYT on Netscape Crack
The New York Times, September 19, 1995, pp. A1, D21. Security Flaw Is Discovered In Software Used in Shopping By John Markoff San Francisco, Sept. 18 -- A serious security flaw has been discovered in Netscape, the most popular software used for computer transactions over the Internet's World Wide Web, threatening to cast a chill over the emerging market for electronic commerce. The flaw, which could enable a knowledgeable criminal to use a computer to break Netscape's security coding system in less than a minute, means that no one using the software can be certain of protecting credit card information, bank account numbers or other types of information that Netscape is supposed to keep private during on-line transactions. The weakness was identified by two first-year graduate students in computer science at the University of California at Berkeley, who published their findings on an Internet mailing list Sunday evening. Although the Netscape Communications Corporation, which produces the software, said today that the flaw could be fixed and that new copies of the software would be distributed as early as next week, Internet experts said the discovery underscored the danger of assuming that any computer security system was safe. "There needs to be much more public auditability in the way these financial security systems are designed and implemented," said Eric Hughes, president of Open Financial Networks, a company in Berkeley that is developing Internet commerce systems. The Netscape software is already used by an estimated eight million people for navigating the World Wide Web portion of the Internet. On the Web, thousands of companies offer text, images, video and audio information, much of it as a way of advertising or directly selling goods and services. Because the Netscape software is not only easy to use but has also been promoted as a secure way of dealing with personal and financial information, it has been seen as the emerging de facto standard for on-line commerce. Already, a diverse group of companies -- including Wells Fargo Bank, MCI Communications, Internet Shopping Network and Virtual Vineyards -- have adopted Netscape as the vehicle for checking bank balances, catalogue shopping or buying wine on line. Although Internet experts agreed with the company's assessment that the flaw could be fixed and that it posed no risk to people who use the World Wide Web only to retrieve nonsensitive data, the security problem's disclosure may represent a public relations setback for Netscape Communications and an inconvenience to millions of people who may feel a need to replace the version of Netscape installed on their computers. Last month the company's shares began public trading and had one of the most successful first days in Wall Street's history, largely on the resounding popularity of the Netscape software. Today, as word of the security flaw circulated only within fairly small circles of Internet users, Netscape's stock closed with a slight loss, down 75 cents, to $52.50, in low Nasdaq trading volume. The company said it would release a repaired version of the software within a week. Users will be able to download it free over the Internet, through the Netscape site on the World Wide Web (http://home.netscape.com). The company had previously announced a next-generation version of Netscape that it said would be more secure than the original, and it said today that it would release this updated version within the next few weeks. But first it will remove the newly disclosed flaw, which is currently in the new version. "The good news and the bad news of the Internet is that when you put something up there, many more people can test it," said Mike Homer, the vice president of marketing at Netscape. "You also give yourself the opportunity of having people point things out which you can fix quickly." The company so far has distributed most copies of its program free over the Internet, under a strategy of making its money from commercial customers who use Netscape to provide services or for other business applications over the World Wide Web. So replacing the copies will not be an expensive undertaking. Instead, for Netscape Communications and for other companies betting their futures on the Internet, the real cost of this disclosure may be in the public's shaken confidence in the ability of computer companies to insure privacy and security for on-line commerce. The weakness in Netscape's security was discovered by Ian Goldberg, 22, and David Wagner, 21, two computer science students who share an office at the university and who also share an interest in the arcane science of cryptography, which is becoming increasingly important for business as companies begin to explore electronic commerce. The two students said they had decided to put the software to a test in an effort to raise public concern about placing too much trust in unproved electronic security systems. Netscape's security is based on a type of coding technology known generically as public key cryptography in which users exchange mathematically generated numbers -- or keys -- to encode or decode information. In such systems, a new key is created for each information exchange, based on a mathematical formula that is combined with numbers supposedly known only to the sender or recipient. The students found that by determining how Netscape's formula generated the number used as a starting point for creating a key, they were able to greatly reduce the potential combinations that would unlock the code. The starting-point number turned out to be based on the time and date of the transaction, combined with several other unique bits of information taken from a user's computer system -- bits of information that an electronic intruder could determine, if he were intent on intercepting a Netscape user's transactions. Knowing how the starting-point number was created greatly reduced the other possible components of the formula -- and the students found they were able to break the code in a matter of seconds using a standard computer work station. Netscape officials said today that they would strengthen the system, by making it significantly harder to determine the random number at the heart of their coding system. They said they would no longer disclose what data would be used to generate the random numbers. The announcement of the flaw was posted Sunday night on a computer network mailing list maintained by an informal group known as Cypherpunks. The group, which is made up of mathematicians, computer experts and privacy advocates, has been campaigning for more effective electronic security systems. The discovery is the second reported security weakness in the Netscape program to be posted on the Cypherpunks list in the last month. In August, Damien Doligez, a student at the Ecole Polytechnique in Paris, used a network of 120 computers, running for eight days, to generate a Netscape secret key. But his was a "brute force" attack, requiring the computers to sample a vast range of numbers before coming up with a key that would break the code. The Berkeley students, in contrast, by identifying a basic flaw in the way Netscape set up its security system, were able to narrowly focus their attack to quickly break the code, with far less computer power. [End]
Markoff's article in the Times says:
Netscape officials said today that they would strengthen the system, by making it significantly harder to determine the random number at the heart of their coding system. They said they would no longer disclose what data would be used to generate the random numbers.
Not, of course, that they disclosed it before -- it was found by reverse engineering the distributed executable. Not, of course, that they have a choice in the matter of whether to disclose it -- they will be "disclosing" how its done as soon as they release the code. Not, of course, that security through obscurity does any good -- it just magnifies the pain. I suspect that there are far more flaws in Netscape. String buffer overflows are another good guess here -- they are probably rampant through the code both for the browser and the commerce server they sell. I can't prove it myself, of course, given that I don't have the time to rip the thing apart, but the same folks never seemed to learn their lesson in release after release when they worked at NCSA, and the only thing thats probably keeping their dignity here is the lack of distributed source code. I'll pay for the "I broke Netscape's Security" T-Shirt for the enterprising person that takes the time to find them in the object code. (See Sameer's page on the shirts he's developing as prizes for the Netscape flaw finders.) Two "I broke Netscape's Security" T-Shirts to that daring soul at Netscape who finds the next flaw and has the balls to mention it in public instead of sweeping it under the carpet -- even if the person is Marc Andreessen. Perry
I suspect that there are far more flaws in Netscape. String buffer overflows are another good guess here -- they are probably rampant through the code both for the browser and the commerce server they sell. I can't prove it myself, of course, given that I don't have the time to rip the thing apart, but the same folks never seemed to learn their lesson in release after release when they worked at NCSA, and the only thing thats probably keeping their dignity here is the lack of distributed source code.
I doubt this in the case of the browser. Atleast as far as the parsing is concerned. There may be a buffer overflow for example, when you input the url in the "open" window, but that has to be done manually by the user and isn't a threat, like a "rogue homepage" would be. The reason I doubt string buffer overflows in the case of the browser is that it seems to be written in some object oriented language, perhaps C++ (or maybe just oo-C like BSAFE). Once you have a general robust String class, you can prove it's non-overflowable, and therefore no composition of operations from the browser code will overflow it (unless of course, you break language safety by using casts and pointer manipulation) Secondly, Netscape has been very robust in my own testing against these common bugs. One of the things I've done lately is "tiger team" attacks against servers and browsers. (of course, sendmail is a brilliant counter example) (if you can find a call to gets() in Netscape, I will instantly retreat ;-) ) Netscape's security maybe bad, but the rest of their browser, or atleast their development process, is good engineering. They've built a very complex application, fairly quickly, that runs with very few bugs, across a wide variety of operating systems and GUI's, while maintaining a consistent user interface and feature set. Netscape 2.0 incorporated Java, LiveObjects, and more HTML3.0 in almost record time. (I wasn't expecting a Java capable Netscape until atleast December). I'd like to see Microsoft develop a piece of code that quickly that runs on umteen different flabors of Unix, MacOS, and Win3.1/95/NT. Hell, they can't even write code that runs smoothly across all three flavors of their operating system. -Ray
I doubt this in the case of the browser. Atleast as far as the parsing is concerned. There may be a buffer overflow for example,
Buffer overflow seems like a much greater concern when dealing with a server. Particularly one which is supposedly "secure", and accessing "secured" documents. Even with the server running as 'nobody' if someone can implement buffer overflow to get access to documents they shouldn't then that would count as a pretty significant hack. I suspect that the server is where the majority of the bugs lie. My Hack Netscape page emphasizes the server as a place to look for holes.
when you input the url in the "open" window, but that has to be done manually by the user and isn't a threat, like a "rogue homepage" would be. The reason I doubt string buffer overflows in the case of the browser is that it seems to be written in some object oriented language, perhaps C++ (or maybe just oo-C like BSAFE). Once you have a general robust String class, you can prove it's non-overflowable, and therefore no composition of operations from the browser code will overflow it (unless of course, you break language safety by using casts and pointer manipulation) Secondly, Netscape has been very robust in my own testing against these common bugs. One of the things I've done lately is "tiger team" attacks against servers and browsers. (of course, sendmail is a brilliant counter example) (if you can find a call to gets() in Netscape, I will instantly retreat ;-) )
Netscape's security maybe bad, but the rest of their browser, or atleast their development process, is good engineering. They've built a very complex application, fairly quickly, that runs with very few bugs, across a wide variety of operating systems and GUI's, while maintaining a consistent user interface and feature set. Netscape 2.0 incorporated Java, LiveObjects, and more HTML3.0 in almost record time. (I wasn't expecting a Java capable Netscape until atleast December). I'd like to see Microsoft develop a piece of code that quickly that runs on umteen different flabors of Unix, MacOS, and Win3.1/95/NT. Hell, they can't even write code that runs smoothly across all three flavors of their operating system.
-Ray
-- 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
I doubt this in the case of the browser. Atleast as far as the parsing is concerned. There may be a buffer overflow for example,
Buffer overflow seems like a much greater concern when dealing with a server. Particularly one which is supposedly "secure", and accessing "secured" documents. Even with the server running as 'nobody' if someone can implement buffer overflow to get access to documents they shouldn't then that would count as a pretty significant hack.
Right. Some other common ones are ".." and shell meta characters in paths. Also, accessing files that you don't have permissions to. Even if the server is perfect, the setup could be bad. For instance, if you use CERN's Authentication scheme for protecting URL hierarchies, do not put the passwd/group file within the hierarchy. I've noticed this before on some servers, like http://www.isp.com/company1/passwd contains the passwd file for the http://www.isp.com/company1/ URL directory. Although it is convenient to store the passwd file within the hierarchy it is protecting, care must be taken to make it unreadable by normal HTTP requests. It's better to put it in a configuration directory somewhere where no server has access to. (I've seen this mistake plenty of times) A barebone's web server is a pretty simple piece of a software compared to a browser (or sendmail), so it should be possible to make them much more secure. -Ray
http://www.isp.com/company1/passwd contains the passwd file for the http://www.isp.com/company1/ URL directory. Although it is convenient to store the passwd file within the hierarchy it is protecting, care must be taken to make it unreadable by normal HTTP requests. It's better to put it in a configuration directory somewhere where no server has access to. (I've seen this mistake plenty of times)
The server process itself still needs access to that file though in order to verify passwords, so it can't be totally protected-- a bug in the server might reveal the password file. A relatively minor point..
A barebone's web server is a pretty simple piece of a software compared to a browser (or sendmail), so it should be possible to make them much more secure.
Right. The Netscape Commerce server, on the other hand, is by no means a barebones webserver. It has a full-featured API which allows dynamic loading of custom-written modules to handle every aspect of web servering. Its configurations files, while not as complex as sendmail config files, are rather complex. The server comes with an "GUI administration tool", which allows you to configure the server using netscape over HTTP to a special server, -running as root-, which can modify configuration files, restart the server, etc. (I am not sure if the administration server -must- run as root, but that is how it has been configured in the installations I have seen.) Even extremely good security programmers could probably not write such a complex program without bugs, particularly on the timescale for which you have commended Netscape. (Extremely good ethical security programmers may not even be -willing- to write such a complex program and declare it secure) There is actually an interesting parallel to sendmail in webservers..webservers have a very vital 'rewriting' phase, where they turn the url (/~sameer for example) into a filename (/u1/sameer/public_html/index.phtml) This phase is where it checks ownership, checks symlinks, etc. I figure that section may be rife with holes, given the incredibly powerful rewriting that the highly flexible servers can do these days. -- 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
The server process itself still needs access to that file though in order to verify passwords, so it can't be totally protected-- a bug in the server might reveal the password file. A relatively minor point..
Actually, it could communicate with a differently-privileged process. The security gain probably isn't worth the performance hit, though. (A possible secure channel: Give the password manager a uid of its own. Have it listen on a unix-domain socket. The server process opens the socket, then fstat()s it to make sure it's really owned by the password manager.) -- Shields.
| Buffer overflow seems like a much greater concern when dealing | with a server. Particularly one which is supposedly "secure", and | accessing "secured" documents. Even with the server running as | 'nobody' if someone can implement buffer overflow to get access to | documents they shouldn't then that would count as a pretty significant | hack. Don't forget system(), which was a major source of holes in the NCSA server. Also, CGI scripts, especially those that run under perl or sh, would be a good place to look for holes. Don't forget to see what happens when you put semi-colons in the data field of various fields, such as mailto:'s. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
Don't forget system(), which was a major source of holes in the NCSA server. Also, CGI scripts, especially those that run under perl or sh, would be a good place to look for holes. Don't forget to see what happens when you put semi-colons in the data field of various fields, such as mailto:'s.
A CGI-script hole doesn't count as a netscape server hole. system() is probably pretty bad though. -- 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
I take a long term view of security. Basically I don't trust security software until it has been released in a stable condition for a few years. The comments about Credit Card numbers miss the point. The volumes of trade on the Internet today are so small that the number of card numbers floating arround is insignificant. There are much easier ways to find them than cracking the Internet. This will not be the case in a couple of years time where the trade volumes are far higher. Visa and Mastercard will be comming out with a spec which will have very tight requirements for implementations. Phill
I've been having mail problems of late. Did you get my letter on your tax issue? --- "In fact, had Bancroft not existed, potestas scientiae in usu est Franklin might have had to invent him." in nihilum nil posse reverti 00B9289C28DC0E55 E16D5378B81E1C96 - Finger for Current Key Information
Black Unicorn writes:
I've been having mail problems of late. Did you get my letter on your tax issue?
Yes, but I've been preoccupied by the latest internet political scandal over domain registration. Thank you greatly for the information; I'll probably ask you a question or two within a few days when my mail volume goes below 500 a day again. Perry
Eek. Lovely accident. Never reply to "all" without checking the "to" list. Sigh. Perry
Not, of course, that they disclosed it before -- it was found by reverse engineering the distributed executable. Not, of course, that they have a choice in the matter of whether to disclose it -- they will be "disclosing" how its done as soon as they release the code. Not, of course, that security through obscurity does any good -- it just magnifies the pain.
Once netscape is patched with a stronger PRNG if someone can crack -that- one too, then they will get a T-shirt as well. Perhaps I should offer the t-shirt for just revealing the algorithim used w/o actually cracking it, just to deal with that statement from "Netscape officials". I emphasized in my conversation with the SFChronicle today that 'security by obscurity' doesn't work. Hopefully that will be reflected in the article. -- sameer Voice: 510-601-9777 Network Administrator FAX: 510-601-9734 Community ConneXion: The NEXUS-Berkeley Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer@c2.org
On Mon, 18 Sep 1995, Perry E. Metzger wrote:
Not, of course, that they disclosed it before -- it was found by reverse engineering the distributed executable. Not, of course, that they have a choice in the matter of whether to disclose it -- they will be "disclosing" how its done as soon as they release the code. Not, of course, that security through obscurity does any good -- it just magnifies the pain.
Well, now that Cypherpunks have again shown yet another hole in Netscape security, I think we are one pretty good standing to demand ACCESS TO SOURCE CODE FOR NETSCAPE, so we can work to help make Netscape "pretty good". Any reporters listening? -Thomas
On Mon, 18 Sep 1995, John Young wrote:
The New York Times, September 19, 1995, pp. A1, D21.
Security Flaw Is Discovered In Software Used in Shopping
By John Markoff
Today, as word of the security flaw circulated only within fairly small circles of Internet users, Netscape's stock closed with a slight loss, down 75 cents, to $52.50, in low Nasdaq trading volume.
Gotta like that open sell order. :) --- "In fact, had Bancroft not existed, potestas scientiae in usu est Franklin might have had to invent him." in nihilum nil posse reverti 00B9289C28DC0E55 E16D5378B81E1C96 - Finger for Current Key Information
In article <199509190355.XAA01329@frankenstein.piermont.com>, perry@piermont.com (Perry E. Metzger) writes:
Markoff's article in the Times says:
Netscape officials said today that they would strengthen the system, by making it significantly harder to determine the random number at the heart of their coding system. They said they would no longer disclose what data would be used to generate the random numbers.
Not, of course, that they disclosed it before -- it was found by reverse engineering the distributed executable. Not, of course, that they have a choice in the matter of whether to disclose it -- they will be "disclosing" how its done as soon as they release the code. Not, of course, that security through obscurity does any good -- it just magnifies the pain.
Regardless of what Markoff implies, we do not intend to depend on security through obscurity.
I suspect that there are far more flaws in Netscape. String buffer overflows are another good guess here -- they are probably rampant through the code both for the browser and the commerce server they sell. I can't prove it myself, of course, given that I don't have the time to rip the thing apart, but the same folks never seemed to learn their lesson in release after release when they worked at NCSA, and the only thing thats probably keeping their dignity here is the lack of distributed source code.
Sigh. For your information the security code for 1.x versions of netscape was not even written by someone from NCSA. The current security team (which does not include the person who did the 1.x version) also does not include anyone from NCSA. While I can't guarantee that such buffer overflow error don't exist in our current products since I have not personally examined every line of code, your generalization from experience with mosaic is bogus. In the places in the code that I have seen where it looked like such errors could have crept in, I have found that the correct checks for buffer overflow have been in place. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
On 19 Sep 1995, Jeff Weinstein wrote:
In article <199509190355.XAA01329@frankenstein.piermont.com>, perry@piermont.com (Perry E. Metzger) writes:
I suspect that there are far more flaws in Netscape. String buffer overflows are another good guess here -- they are probably rampant through the code both for the browser and the commerce server they .... Sigh. For your information the security code for 1.x versions of netscape was not even written by someone from NCSA. The current security team (which does not include the person who did the 1.x version) also does not include anyone from NCSA. While I can't
I will defend Netscapes code on the point about the RNG even though I have not seen any. I assume the Netscape code is quite large and each release would have to pass various fuctionality tests. How can you test that the RND seeding is wrong? You have to actually look at the code, the number coming out are still random. As of last week I was told by Mike_Spreitzer.PARC@xerox.com that the random number generator seed routine in my DES library was only copying in 4 bytes of passed data instead of 8. Given des_cblock data;, it was memcpy(init,data,sizeof(data)); it should have been memcpy(init,data,sizeof(des_cblock)); Rather hard to notice unless you know that des_cblock is passed as a pointer and even this can be compiler dependent. Now I had not noticed this, my library runs like a charm and things appear random from the random number generator. This sort of error can only be checked by reading the code and specifically looking at critical routines like this the RNG seeding routines. The advantage of my code being public is that some-one like Mike can have a look and pick up problems like this. The moral of the story I suppose is to be paranoid about checking routines relating to RNG. What would be interesting is to see if packages like PEM use similar simple systems for generating random data. Any of the systems that do digital envelopes are relying on libraries to provide random data for encryption keys. At least with the old 'enter passwd' type encryption there was a bit of secret random data coming from a human, pitty about packet watchers seeing those characters as they fly over the net :-) eric (who has also been burned by dodgy RNG seed routines in the past and so now uses a rather extrem system involving MD5 and lots of state :-). -- Eric Young | Signature removed since it was generating AARNet: eay@mincom.oz.au | more followups than the message contents :-)
Eric Young writes:
Sigh. For your information the security code for 1.x versions of netscape was not even written by someone from NCSA. The current security team (which does not include the person who did the 1.x version) also does not include anyone from NCSA. While I can't
I will defend Netscapes code on the point about the RNG even though I have not seen any. I assume the Netscape code is quite large and each release would have to pass various fuctionality tests. How can you test that the RND seeding is wrong?
The seeding isn't "wrong"; it's a design flaw. (At least that's my understanding; maybe I missed something.)
You have to actually look at the code, the number coming out are still random.
Two words: "design review".
This sort of error can only be checked by reading the code and specifically looking at critical routines like this the RNG seeding routines.
Uhh... OK. Sounds like a plan to me. For critical pieces of code like that, having repeated exhaustive design/implementation reviews should be a matter of course. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Weinstein writes:
I suspect that there are far more flaws in Netscape. String buffer overflows are another good guess here -- they are probably rampant through the code both for the browser and the commerce server they sell. I can't prove it myself, of course, given that I don't have the time to rip the thing apart, but the same folks never seemed to learn their lesson in release after release when they worked at NCSA, and the only thing thats probably keeping their dignity here is the lack of distributed source code.
Sigh. For your information the security code for 1.x versions of netscape was not even written by someone from NCSA.
If there is ANY place in the code that I can do a data driven buffer overflow, I can force you to execute code that I supply. I don't give a damn if it's in the "security" code. It makes no difference where it is. If there is a chink, thats it -- you're meat. Besides, the "security code" obviously was written by someone who doesn't understand anything about cryptography and yet presumed to play cryptographer. A person who thinks seeding things off the time makes for a good PRNG is capable of almost anything.
In the places in the code that I have seen where it looked like such errors could have crept in, I have found that the correct checks for buffer overflow have been in place.
I have very serious doubts in this regard -- VERY serious doubts, especially given what I've been told by several former Netscape employees. Perry
Sigh. For your information the security code for 1.x versions of netscape was not even written by someone from NCSA.
If there is ANY place in the code that I can do a data driven buffer overflow, I can force you to execute code that I supply. I don't give a damn if it's in the "security" code. It makes no difference where it is. If there is a chink, thats it -- you're meat.
How would you do this if the buffer overflow happened in a buffer which was allocated in a separate protected heap apart from stack and executable data? -Ray
Ray Cromwell writes:
Sigh. For your information the security code for 1.x versions of netscape was not even written by someone from NCSA.
If there is ANY place in the code that I can do a data driven buffer overflow, I can force you to execute code that I supply. I don't give a damn if it's in the "security" code. It makes no difference where it is. If there is a chink, thats it -- you're meat.
How would you do this if the buffer overflow happened in a buffer which was allocated in a separate protected heap apart from stack and executable data?
You could do that, but thats not how C does things. C allocates these things on the stack. Overflow the buffer and you fandango on stack, allowing you to change where the program counter jumps to on subroutine exit, and allowing you to force your own machine code into the system for execution. I suspect that even were subroutine data allocated in a seperate heap you could pull nasty tricks -- your protected heap probably has data in it that controls execution flow, so cleverness might still get you the same results. Perry
The New York Times, September 19, 1995, pp. A1, D21. ... Netscape officials said today that they would strengthen the system, by making it significantly harder to determine the random number at the heart of their coding system. They said they would no longer disclose what data would be used to generate the random numbers.
and from the WSJ article:
"The information we were using to create the key is now a known set of information," said Jeffrey Treuhaft, security product manager for Netscape.
It sounds as if Netscape thinks that public knowledge of the key generation is part of the problem. I hope somebody on the security team convinces management that entropy is more important than publicity. (This could be a result of journalistic cluelessness, but it came up in two independent articles. It's enough to worry me.) -- Eli Brandt eli+@cs.cmu.edu (back from a nice long mailing-list vacation -- it's nice to see that cpunks is still at the cutting edge. for them what cares, I'm now a Ph.D. student at the CMU CS program...)
On Tue, 19 Sep 1995, Eli Brandt wrote:
It sounds as if Netscape thinks that public knowledge of the key generation is part of the problem. I hope somebody on the security team convinces management that entropy is more important than publicity.
No matter what they say in the press, I doubt it will take more than a few weeks to reverse engineer the new RNG seeder and figure out where the data comes from. I am hoping it was more of a PR thing than a technical thing. I hope that Netscape tells us their RNG seed so Cyperhpunks don't have to go to all the trouble. If they tell us, we can let them know if it is a reasonable mechanism or bogus. -Thomas
participants (13)
-
Adam Shostack -
Black Unicorn -
Eli Brandt -
Eric Young -
hallam＠w3.org -
John Young -
jsw＠neon.netscape.com -
m5＠dev.tivoli.com -
Perry E. Metzger -
Ray Cromwell -
sameer -
shields＠tembel.org -
Thomas Grant Edwards