netscape's response
" With this knowledge, an experienced computer programmer could decrypt messages sent by Netscape Navigator to other computers in a few hours of computation time." Excuse me? A few hours? Try 25 seconds?? "Netscape has also begun to engage an external group of world-class security experts who will review our solution to this problem before it is sent to customers." A group which offered to review the first version, but Netscape refused. From their release it looks like they aren't finding a better source of entropy, but just using *more* sources of entropy. Doesn't mean that the entropy is good. A T-shirt to the first person to decompile the new Seed code and post the sources of "entropy" used. (See http://www.c2.org/hacknetscape for general [not written in stone] guidelines regarding t-shirt awards) -- 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
In article <199509192304.QAA05546@infinity.c2.org>, sameer@c2.org (sameer) writes:
" With this knowledge, an experienced computer programmer could decrypt messages sent by Netscape Navigator to other computers in a few hours of computation time."
Excuse me? A few hours? Try 25 seconds??
DISCLAIMER: my comments below are my opinion, and not necessarily the position of Netscape. Yes, it was < 1 minute if you had captured the client-hello message, and had access to the machine that was running the Navigator, and it was a unix machine and it was not an SGI with a high-resolution timer. If the attacker does not have access to the machine to determine the pid and ppid, then the attack will take longer. If the Navigator is running on an SGI machine with a high resolution cycle counter then it is used as the first of the two 32bit seeds. If the Navigator is running on a Mac or PC, then the two seeds are the current time and the "tick count", which is milliseconds since starting windows for the PC version, and some time unit since booting on the Mac. I believe that it would take much longer than 1 minute to mount an attack against a mac, pc, or unix machine that the attacker was not logged on to. I don't know exactly how the few hour number was calculated, since it was done by marketing with input from someone else in the group. Another interesting data point is that the unix version, which was most vulnerable, accounts for less than 10% of our user base, according to the yahoo random link stats. 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. 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.
"Netscape has also begun to engage an external group of world-class security experts who will review our solution to this problem before it is sent to customers."
A group which offered to review the first version, but Netscape refused.
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.
From their release it looks like they aren't finding a better source of entropy, but just using *more* sources of entropy. Doesn't mean that the entropy is good.
I would love to hear your suggestions for good sources of entropy on any systems that our products run on.
A T-shirt to the first person to decompile the new Seed code and post the sources of "entropy" used.
Is this offer good for netscape employees? What if I post the code without having had to decompile it? :-) --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
| 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. It isn't really easy. I guess you were around to see the pointer to RFC 1750, approx "Security Randomness reqs"? | 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 you should use as much user-generated randomness as possible, like the mouse movement patterns, interarrival times of events from the user interface etc. * You can also gather statistics from the networking card, like number of collisions, packets in/out, number of passing packets etc. * Measuring the interarrival times of requests/responses from a remote server should also be a good one, I guess. I depends on the network in between, the actual processes executing on it, the scheduling algorithm etc. * And finally, insert some sampling of the noise in the sound blaster. * And try to reseed it, as often as possible and convenient. Make it depend on the previous value of the random generator seed, somehow. The difficult part is to verify the quality of the random seeding and reseeding. How does it behave on a unloaded system? Could someone put your system under some strain, and hence affect the random generator to lock down into a small subspace or even onto a fixed value? How independant are the values anyway? And when you start to talk about ergodity etc, I'm lost anyway. :-) I think it is important to bring together factors of the user _and_ the environment, preferrable an environment that reaches as far from the local site as possible. This makes "jamming" of the random seed selection process harder. The other problem in gathering random bits for a seed is that most bits are visible by someone else close enough within your environment. Interarrival times of packets are fine, but anyone can observe them with quite a good accuracy. How do you escape the "local environment problem"? . - . One wild idea that I just got was to have servers and clients exchange random numbers (not seeds of course), in a kind of chaining way. Since most viewers connect to a number of servers, and all servers are connected to by many clients, they would mix "randomness sources" with each other, making it impossible to observe the local environment only. And the random values would of course be encrypted under the session key, making it impossible to "watch the wire". Problems: * watch out for "multiply by zero" attacks by a rogue server/client. * watch out for "almost singular values" in the same way. * only let one source contribute a certain amount of randomness, like (key length)/(aver # of peers). * never reveal your current seed, only a non-trivially derived random value from it. (of course) * make sure your initial seed is good enough, or the whole thing is broken. * perhaps save part of the previous session state into a protected file, to be able to keep up the quality of the initial seed. I think I like it, perhaps not from a practical point of view as much as the 'non-attackability' of it. Its quite cypher-a. But I bet someone has already done this a long time ago. My usual luck! :-( If not, I want a 'I saved Netscape!' t-shirt from you, Jeff! /Christian PS. I'm a Swede, I don't know if I'm allowed to reveal these state secrets. So please shut your eyes, ok?
On Sep 20, 12:29am, Christian Wettergren wrote:
Subject: Re: netscape's response One wild idea that I just got was to have servers and clients exchange random numbers (not seeds of course), in a kind of chaining way. Since most viewers connect to a number of servers, and all servers are connected to by many clients, they would mix "randomness sources" with each other, making it impossible to observe the local environment only. And the random values would of course be encrypted under the session key, making it impossible to "watch the wire".
Wow, this is a great idea!! SSL already sends various encrypted random values back and forth between client and server, so this may not be too hard to implement without changing the protocol. I'll keep it in the back of my mind for when I have some time... --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
-----BEGIN PGP SIGNED MESSAGE----- Hello cypherpunks@toad.com and Christian Wettergren <cwe@Csli.Stanford.EDU> Christian Wettergren wrote: ...
One wild idea that I just got was to have servers and clients exchange random numbers (not seeds of course), in a kind of chaining way. Since ...
Okay, that doesn't sound so hard... Have a look at http://www.cs.monash.edu.au/cgi-bin/cgiwrap/~jirib/random?RandValue where you replace RandValue by any text string. Please do not try to break the implementation, I *know* you can overrun buffers, use shell metacharacters and generally stuff around. Just don't, OK? Thanks. Feel free to try to break the algorithm, though.
Problems: * watch out for "multiply by zero" attacks by a rogue server/client. * watch out for "almost singular values" in the same way.
Don't know about these...
* only let one source contribute a certain amount of randomness, like (key length)/(aver # of peers).
Well I don't keep track of entropy, so that doesn't apply, does it...
* never reveal your current seed, only a non-trivially derived random value from it. (of course)
I reveal md5 hash of my seed only.
* make sure your initial seed is good enough, or the whole thing is broken.
Well, entropy put in must be greater than entropy used or lost through cracked connections. (Ie not just "initial", also entropy put in along the way.) I fail this point either way.
* perhaps save part of the previous session state into a protected file, to be able to keep up the quality of the initial seed.
Yup, I do that (though "quality" would be quite a bit of a euphemism, and the file is hardly protected at all). Have fun! Jiri - -- <jirib@cs.monash.edu.au> <jiri@melb.dialix.oz.au> PGP 463A14D5 -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQCVAwUBMGDnpixV6mvvBgf5AQEExQQAsqCTmTOI0aT7YBnCsYyvEp0y3gWFFZdf qbG5wvpFGvJMvRxn8A61AEeX0CkQ7ZLVDwAo4K6N+SGMeXDWKkUtHRBS1cHomgJP Kf98rFxHXp3SS1eXUKEyzlcY0zkXQ4wunR7nsBAlvVVPcexINZ2++2bFKyyUKNTm KZ39Fj1TEf4= =oC33 -----END PGP SIGNATURE-----
Is this offer good for netscape employees? What if I post the code without having had to decompile it? :-)
That depends on whether or not you do it with the approval of your superiors. ;-) Seriously, if you manage to convince the management/whoever-needs-to-decide a significant portion of the security code can be released for public scrutiny, you deserve a t-shirt. The goal here is to have a piece of software we can trust. -- 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
If the attacker does not have access to the machine to determine the pid and ppid, then the attack will take longer. If the Navigator is running on an SGI machine with a high resolution cycle counter then it is used as the first of the two 32bit seeds.
The release mentioned "computation time". In my book that doesn't include the setup time involved in figureing out how to snag the packets, sending the sendmail spoofs in order to approximate the pid and ppid, etc.
I believe that it would take much longer than 1 minute to mount an attack against a mac, pc, or unix machine that the attacker was not
"time to mount an attack" is not "computation time". I'm really not debating with -you- though here, just describing how the release was inaccurate. I don't deny any of your statements
logged on to. I don't know exactly how the few hour number was calculated, since it was done by marketing with input from someone else in the group. Another interesting data point is that the unix version, which was most vulnerable, accounts for less than 10% of our user base, according to the yahoo random link stats.
Is UNIX really the most vulnerable? How many bits did the tickcount account for? Seems to me that guessing just time & tick would be easier than guessing time, pid and ppid if you are not logged into the machine in question. . .
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.
I don't know what your background is, so don't take this as a personal attack please, but someone who is trained in computer security and cryptography implementation should *know* to check these things. Hell, even I would check those things, and I'm not a cryptographer by any means.
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.
Again, Kudos to Netscape for the quick response.
A group which offered to review the first version, but Netscape refused.
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.
I was referring to Jim Bidzos's comment, posted to cypherpunks. The release I will be sending out is written much more cleanly than what I initially posted to cypherpunks.
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.
Great!
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.
Ah but who's to stop an anonymous posting. nudgenudge. ;) (This is a -joke-, for those excessively humor impaired)
From their release it looks like they aren't finding a better source of entropy, but just using *more* sources of entropy. Doesn't mean that the entropy is good.
I would love to hear your suggestions for good sources of entropy on any systems that our products run on.
When I wrote that sentence I misread the release -- my apologies-- my initial reading gave me the impression that the only thing that was being done was increasing the key size to 300 with no additional work towards finding sources of randomness, which you have said you were working on. -- 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
but someone who is trained in computer security and cryptography implementation should *know* to check these things.
Upon consideration, I am going to retract this statement-- I suppose you can't check -everything-. (I still blame Netscape for shoddy crypto in the first place, just not Jeff in particular) -- 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
On Sep 20, 1:25am, sameer wrote:
Subject: Re: netscape's response
but someone who is trained in computer security and cryptography implementation should *know* to check these things.
Upon consideration, I am going to retract this statement-- I suppose you can't check -everything-. (I still blame Netscape for shoddy crypto in the first place, just not Jeff in particular)
It turns out that Taher Elgamal and I started working here within a week of each other, about 6 months ago. Neither of us thought to take a serious look at the RNG seed code. I don't think that anyone would accuse Taher of being an amateur in this area. I for one just didn't think about it enough to realize that while we got the RNG code from RSA, they did not provide seed code. As for my background, I am not a trained cryptographer, but I do understand protocols, did some internet security work as a sysadmin while in school, and have had a casual interest in crypto stuff for several years. If you want the gory details see my web page... --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" writes:
It turns out that Taher Elgamal and I started working here within a week of each other, about 6 months ago. Neither of us thought to take a serious look at the RNG seed code. I don't think that anyone would accuse Taher of being an amateur in this area.
Well, he is more of a math guy than a practical guy. For a long time, I've posted articles and have seen other people post articles arguing that the right place to attack systems like this is in spots like the random number generators. Were I Netscape, I'd be conducting code reviews for lots of other things, too. Your coding standards should out and out ban the use, anywhere in your code, of sprintf, gets, strcat, or any other thing that manipulates strings without explicitly taking length limits. system and any similar calls should also be banned entirely. It doesn't matter if you "think" they are safe -- calls you don't use can't be somehow trickily abused. I suspect, however, that the seductiveness of "oh, this looks safe enough" will probably continue to win out with your colleagues over systematic approaches to these problems. After all, they never seemed to learn the lesson in revision after revision of NCSA's stuff. This is not to say that I think *you* are bad at this, Mr. Weinstein, but you certainly have colleagues with the worst possible track record. Perry
On Sep 20, 1:12am, sameer wrote:
I believe that it would take much longer than 1 minute to mount an attack against a mac, pc, or unix machine that the attacker was not
"time to mount an attack" is not "computation time".
I'm really not debating with -you- though here, just describing how the release was inaccurate. I don't deny any of your statements
The issue is that any statement that only mentions the 1 minute figure is only stating part of the story, just as a statement giving a figure of several hours is only mentioning a part of the story. All of the news articles I've seen (not an exhaustive sample) have only mentioned the 1 minute number, which only really effects a relatively small number of our customers. If you don't know the pid and ppid, or the tick count in the case of Mac/PC, you will have to add them to your search, which could make it take much longer than 1 minute to crack. If you assume that the unix machine has been up for a while and has a decent turnover of processes (not a valid assumption for determining strength) then you would have to search on average half of 16 bit pid space, and then add a few bits for the ppid(assuming that it is likely to be close to the pid). Even if you only got 8 extra bits from pid and ppid, that turns your one minute attack into a several hour attack. Anyway, I'm not trying to say that "several hours" is the only answer, just that it is just as good an answer as "one minute". As far as I know, no one has tried this attack without knowing the pids.
logged on to. I don't know exactly how the few hour number was calculated, since it was done by marketing with input from someone else in the group. Another interesting data point is that the unix version, which was most vulnerable, accounts for less than 10% of our user base, according to the yahoo random link stats.
Is UNIX really the most vulnerable? How many bits did the tickcount account for? Seems to me that guessing just time & tick would be easier than guessing time, pid and ppid if you are not logged into the machine in question. . .
This is really dependent on how long window has been running. If you boot windows and immediately start an ssl connection, then the number will be pretty low, but if you don't make the first SSL connection until later, it should get better. I think an hour would get you around 16-bits, but this is just a guestimate on my part. If you leave your machine running windows for days you will get close to 32bits.
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.
I was referring to Jim Bidzos's comment, posted to cypherpunks. The release I will be sending out is written much more cleanly than what I initially posted to cypherpunks.
We had a conference call with RSA folks tuesday, and they will be in wednesday to take a look at our fix. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
In article <9509200248.ZM206@tofuhut>, Jeff Weinstein <jsw@netscape.com> wrote:
On Sep 20, 1:12am, sameer wrote:
Is UNIX really the most vulnerable? How many bits did the tickcount account for? Seems to me that guessing just time & tick would be easier than guessing time, pid and ppid if you are not logged into the machine in question. . .
This is really dependent on how long window has been running. If you boot windows and immediately start an ssl connection, then the number will be pretty low, but if you don't make the first SSL connection until later, it should get better. I think an hour would get you around 16-bits, but this is just a guestimate on my part. If you leave your machine running windows for days you will get close to 32bits.
But you don't have the usec at all, if I read your post correctly. Windoze uses the time in seconds (essentially 0 bits of randomness, maybe a couple, since Windoze machines don't set their clocks very well), and the tick count. In one hour, the tick counts counts to 3600*1000, or about 22 bits. Many hours given another bit or two. Thus, in total, given *no* information except the assumption that the clock is reasonably accurate, you get at *most* 25 bits. Since our code can do 21 bits in 1 minute, we'll need 16 minutes. - Ian
-----BEGIN PGP SIGNED MESSAGE----- Jeff-- First of all, let me commend you for your honesty and forthrightness in owning up to the problem. I applaud it both as a cypherpunk and as one of the guys at Intergraph who pushed really hard to get an OEM agreement with NCC.
If the Navigator is running on a Mac or PC, then the two seeds are the current time and the "tick count", which is milliseconds since starting windows for the PC version, and some time unit since booting on the Mac.
The Mac tick unit is 1/60th of a second, and TickCount() returns the number of ticks since the system was booted. I think you could safely narrow the range down to between 0 and (3600 * 24 * 60 =) 5,184,000, or about 24 bits. That's better than on the Unix boxes, but not insurmountable.
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 wouldn't consider the network to be suitably random. How many of your users are using Netscape over high-latency, low-speed 14.4 PPP/SLIP links? A lot, I'd bet. Not much good-quality randomness there.
"Netscape has also begun to engage an external group of world-class security experts who will review our solution to this problem before it is sent to customers."
A group which offered to review the first version, but Netscape refused.
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.
Unrealistic to expect, yes. Unreasonable to ask? Maybe not.
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.
That's probably not the most likely thing-- but why not allow people with some security & crypto background _from this list_ see the code, under NDA, for review? Jim Gillogly, Hal Finney, and several others have show a past talent for that sort of thing. Frankly, a signed message from, say, Hal saying "I've looked over the code and it looks pretty good" would carry a lot of water with me. In turn, I could communicate my warm fuzzy feeling to the dozen or so people that asked me about the security flaw yesterday, including our network ops guy. Cheers, - -Paul - -- Paul Robichaux, KD4JZG | "Things are much simpler and less stressful perobich@ingr.com | when you don't look to the law to fix things." Not speaking for Intergraph | - Tim May (tcmay@got.net) on cypherpunks Be a cryptography user. Ask me how. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMGANAafb4pLe9tolAQH+uQP7B7XvqVGnN4rDnSNth2PyVio5W5CpuA2U DgWwjV1DqPJCzA4BmM3/rRlYYG8Z2d50i5zb0XD6XbMi6bpkc9fGBZ6156p7sKa1 DDk8hWAr+BvIcuYTC2irRTee7462YBjsBvwOiFVV+0/Wdbg2gjGfPgcmsxmzqi4R Tby1/d2Pr6c= =xm2W -----END PGP SIGNATURE-----
participants (8)
-
Christian Wettergren -
iagoldbe＠csclub.uwaterloo.ca -
Jeff Weinstein -
Jiri Baum -
jsw＠neon.netscape.com -
paul＠poboy.b17c.ingr.com -
Perry E. Metzger -
sameer