Maybe It's Snake Oil All the Way Down

[Ian Grigg]

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 at metzdowd.com