netscape's response

[sameer]

> 
>   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 at c2.org