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