Eric Murray wrote:
On Mon, Jun 02, 2003 at 10:09:06AM -0400, Ian Grigg wrote:
A lot of the tools and blocks are too hard to understand. "Inaccessible" might be the proper term. This might apply to, for example, SSL, and more so to IPSec. These have a lower survival rate, simply because as developers look at them, their eyes glaze over and they move on. I heard one guy say that "you can read SSH in an hour and understand what's going on, but not SSL."
Some who can't understand SSL won't be able to do better. Especially since there is at least one very good book on it.
That presupposes that one can do "better" using SSL because SSL is "better". It is a challenge to translate SSL's strong peer reviewed heritage into a secure crypto system. In practice, if the tool is hard to use, an implementation opens itself up for problems in its usage of SSL. There can be bugs in the interface, bugs in the architecture reflected by the complexity of the interface, and there can be bugs in the underlying tools. 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.
Also, a lot of cryptosystems are put together by committees. SSH was originally put together by one guy. He did the lot.
The original SSH protocol had holes so large that you could drive a truck through them. Tatu posted it to various lists and got lots of advice on how to clean it up. It still had holes that were being found years later.
Yep. But the application got up and going, he didn't wait for the protocol to be perfected, which mean that the the application had a much greater chance of ultimate success, and many more scenarios were protected than otherwise would have been. Now it's a good protocol (Peter G reports that it is highly analogous to SSL, but with its own packet formats). It's hole-filled first effort doesn't seem to have done it so much harm.
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?). ]
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. Hence, SSL as a protocol might be a fine piece of work. SSL as a browsing application is flawed, and that's partly because too many different people and agendas were involved. (I think the design-by-committee criticism would stick more strongly to IPSec.)
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.
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. ...
which allows you to
4. Concentrate on the application, not the crypto.
Rolling your own crypto is where 95% of crypto apps fail... the developers either take too much time on it to the detrimient of the useability because it is the sexy thing to work on, or they write an insecure algorithm/protocol/system. Usually they do both!
It's true that if there is a perfectly good alternative available, it is probably more expensive to roll your own than to use the perfectly good alternative. 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. It's also very much oriented to x.509 and similar certificate/PKI models, which means it is difficult to use in web of trust (I know this because we started on the path of adding web of trust and text signing features to x.509 before going back to OpenPGP), financial and nymous applications whereby trust is bootstrapped a different way. 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. In contrast, using a black box is always a big risk. Which black box? There are always 10 experts for every black box out there, and they are all asking for lots of bux to say they're right. And, traditionally, when you buy in a black box, chances are, it's a grey box, or it's a black bucket, or...
From the outside world's point of view, it still seems a very plausible decision to roll ones own crypto.
( Has anyone read Ferguson and Schneier's _Practical Cryptography_ ? Does it address this issue of how an outsider decides how to "make or buy"? I just read the reviews on Amazon, they are ... entertaining! http://www.amazon.com/exec/obidos/tg/detail/-/0471223573/qid=1054578908/sr=8-1/ref=sr_8_1/103-4510729-0384610?v=glance&s=books&n=507846 ) -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com