1995-09-19 - Re: NYT on Netscape Crack

Header Data

From: aba@dcs.exeter.ac.uk
To: andrew_loewenstern@com.swissbank.us.il
Message Hash: c751aaf36e8621b386af7f8cf1e439c055927aab36e2582b89053f002e4d245b
Message ID: <429.9509191807@exe.dcs.exeter.ac.uk>
Reply To: <9509191738.AA00941@ch1d157nwk>
UTC Datetime: 1995-09-19 18:08:54 UTC
Raw Date: Tue, 19 Sep 95 11:08:54 PDT

Raw message

From: aba@dcs.exeter.ac.uk
Date: Tue, 19 Sep 95 11:08:54 PDT
To: andrew_loewenstern@com.swissbank.us.il
Subject: Re: NYT on Netscape Crack
In-Reply-To: <9509191738.AA00941@ch1d157nwk>
Message-ID: <429.9509191807@exe.dcs.exeter.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain



Andrew Loewenstern <andrew_loewenstern@il.us.swissbank.com> writes:
> Ian posted the code for the PRNG on August 30th and Stephen Kapp
> noted that it was similar to one in RSAREF.  The PRNG is probably
> fine.  

Yeah I saw both.

> The big flaw here was the collection of seed material.  

This was what I was trying to say.  I was thinking that it would be
useful if they would care to disclose this part of the implementation,
where the entropy comes from, and how they estimate it.

> The bottom line is the WHOLE security subsystem should be published
> for analysis.

Absolutely, but can you see netscape adopting the GPL, with full
source availability?  Of course this would be ideal, but I was hoping
for at least the source as pertaining to the random number generator
which is the essence of the current problem.

> > Or if that doesn't sit well with copyright interests, how about
> > writing up an open spec about how the random number generator works?
> > Then we can critique it.
> 
> Netscape did this with SSL and what happened was the rest of the industry  
> jumped on it before any analysis was done.  Now we are likely stuck with a  
> poor protocol.

Yeah well if open systems is taken to mean, we make up a standard,
tell you about it and if you don't like it well it's too late because
we've blasted it across the internet to the extent that there's no
turning back.

An approach more in keeping with the IETF frame work would have been
better.  If it's open standards why not accept existing standards, or
contribute to a IETF working group to decide one which is agreed upon.
I'd call that more open.

> > An algorithm should be something to be proud of, "it's secure, and
> > see:  this is how it works, here are the design criteria, here is
> > how you would attempt to break it, and here is the best predicted
> > attack's cost."
>
> The design may be great, but if the implementation is flawed then
> you aren't much better off.  To attempt to evaluate the security of
> a system you need to be able to inspect the implementation.  Period.

Well yes, but the current flaw the design wasn't even correct,
although the implementation of that design was.  Both would be ideal
but a design and proof of having audited it would be good if they are
expecting people to trust this thing for megabucks as internet
commerce takes off.

> Netscape may have hot programmers but so far I believe it has become
> self-evident that they know little about crypto and implementing
> cryptosystems.

yup.

> To Netscape's credit, Jeff Weinstein claims that the team
> implementing the security for Navigator 2.0 is completely new and of
> course Netscape has hired Tahir ElGamal, who certainly knows what he
> is doing.  Additionally I would suspect that with all the bad
> publicity they are receiving they would take up Bidzos on RSADSI's
> offer to analyze the source.  So it is entirely possible that
> Navigator 2.0 will be much better.  However, I am not holding my
> breath.

Well I highly doubt they'd GPL the code.  Or even make the code
available.  But it would be really, really nice if a fresh outlook was
taken on this, code is required to trust the thing, as that shows a
willingness to expose the workings, and confidence in the
implementation, and algorithms.  I hope some serious thought goes into
this issue at netscape, about giving out code for their security
implementation.

There are still possibilities for server bugs, and so on.

> Strong crypto is _hard_ to implement properly.  Even if a product is
> using a well-known algorithm there could be any number of subtle
> flaws that can destroy any security offered by such algorithm.  You
> can't just toss in RSA, IDEA, RC-4, DES, etc... and claim the thing
> is secure.

No, you can't.

Sadly, I presume that they have no intention of releasing source.  So
we'll have to be content with RSADSI security audit.  Or another
break.

Adam






Thread