Admitting that in some of the preceding I've used an occasional unnecessarily direct phrase, I'd just like to offer a final, short summary of my proposition:
Computer security landscape is unsatisfactory.
You got that right. Question is, why? And, seeing as us Internet security people have been doing this for a decade, do we have a good reason to do what we've been doing all that time, or, maybe thinking about changing the way we do things?
> There
are many possible directions in which we could move to improve it: of these most acknowledged experts favour automating things to an even higher degree, at both crypto tool and application software fronts.
I disagree with that path, partly because it hasn't worked in the past, and partly because there's no fun being the same as everyone else :)
I believe however that - for reasons of software engineering practicalities - such efforts have reached the point of diminishing returns, and that we should instead put more effort into making both the crypto library and application software users better equipped to use simpler tools with greater proficiency.
I think there is something we also have to recognise in applications building: developers don't have any time to use, learn, select, or verify good security.
That applies as much to good products as it does to the schlock. It applies to the code their write, as much as the protocols they hack together.
It seems to be that every new product there is faced with four choices:
1. do no security;
2. do a quick and nasty home built hack
of a protocol; 3. create a good, aligned, secure,
precise and appropriate crypto protocol; 4. use a standard tool that is already
built, reviewed, tested and safe.Everyone suggests 4., but, that's too hard, because one still has to select the right one, or to pick the wrong one and then slave through the horribly hard API and all the special hooks and the "must-do-else-your-cat-fries" security parts...
So, 4. is out. Sorry, SSL guys, it's just too hard. Then, 3. is easily dispensed with, as those wunderkinder just don't exist.
Which leaves 1 or 2: Nothing or somthing really quick and dirty, and probably only somewhat secure.
This is the SSH story. SSH 1 was widely thought to be pretty loose. What happened? It succeeded, partly because the author didn't worry overly about having perfect crypto - he rocked on ahead with something that was "ok".
Later on, when the product was a wild success, and the model was proven, there was a chance (somewhat costly) to repair that protocol, essentially by taking the good stuff from another protocol and grafting it in.
In sum, I think the future in crypto, when it ever gets past 1. above, is at 2: we should consider ourselves lucky if a successful product has stuck some schlock in there, and there's an opportunity to come in later and clean it up.
In that sense - Tom's crypto lib (PG mentioned the name) is the best thing that's happened in crypto libraries in a long time. Quick and dirty, fast and furious - lets the application developer slap in something now, and clean it up later.
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
