Eric Murray wrote: It may be that the SSL underlying code is perfect. But that the application is weak because the implementor didn't understand how to drive it; in which case, if he can roll his own, he may end up with a more secure overall package. I don't think this is likely to be true. In my experience,
Ian Grigg <iang@systemics.com> writes: people who learn enough to design their own thing also learn enough to be able to do SSL properly.
SSLv2, which was also designed by an individual, also had major flaws. And that was the second cut! I haven't seen v1, maybe Eric can shed some light on how bad it was.
[ Someone commented before that v1 was not deemed serious (Marc A?) and v2 was the more acceptable starting point (Weinsteins?). ] That's not true as far as I know. V1 and V2 were designed by the same guy (Kipp Hickman). V1 is actually very similar to V2, except that the integrity stuff is all screwed up. As far as I can tell, the fact of the matter is that Kipp didn't understand the security issues until Abadi and to some extent Schiffman sold them some clues.
Peer review is not "design by comittie".
Let me clarify. SSL - the protocol - was not designed by committee, but, the size of the teams involved in the crypto systems was in excess of the people who were intimately familiar with the protocol. For the most familiar example, browsing, there were, it seems, many people involved in the overall grafting of SSL into the original HTML/HTTP system. As far as I know, that's not the case. The original Netscape team was very small and there really weren't any significant choices to be made.
It is the way to get strong protocols. When I have to roll my own (usually because its working in a limited environment and I don't have a choice) I get it reviewed. The protocol designer usually misses something in his own protocol.
Sure. If someone does roll their own, then they should get it reviewed. That's not my experience. WEP and PPTP come to mind.
I'd say that conditions for Internet crypto system success would include:
0. USE EXISTING SECURITY PRIMITIVES
:-)
I know this is the mantra of the field.
Quesion is: which PRIMITIVES?
1. RSA? 2. SSL, written from the RFC? 3. OpenSSL, the toolkit? EKR's fine effort? 4. RSADSI security consultants, selling you theirs? 5. ... I would say the highest level primitives you can get away with.
But, that assumes an awful lot. For a start, that it exists. SSL is touted as the answer to everything, but it seems to be a connection oriented protocol, which would make it less use for speech, media, mail, chat (?), by way of example. SSL is quite fine for chat, actually. It's one of the major things that people use for IM. The issue with speech and media isn't connection-orientation but rather datagram versus stream data.
Then there is understanding, both of the protocol, and the project's needs. I know that when I'm in a big project and I come across a complex new requirement, often, it is an open question as to whether make or buy is the appropriate choice. I do know that 'make' will always teach me about the subject, and eventually, it will teach me which one to buy, or it will give me a system tuned to my needs. The history of people who go this course suggests otherwise. They generally get lousy solutions.
-Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com