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