Re: Anyone looked at Mithra ?

From: Will Dickson (wrd_at_glaurung.demon.co.uk)
Date: 05/08/03 

Date: Thu, 08 May 2003 00:04:44 +0100

daw@mozart.cs.berkeley.edu (David Wagner) wrote:

>Martin4 wrote:
>>DDJ's target audience is largely the hands-on "roll your own" crowd
>>anyway, those who are strongly disinclined to adopt a mechanism that
>>works in a (for them) highly non-intuitive manner, and winds up being
>>more complex than they can fathom without going through grad school...
>
>I prefer to believe that DDJ's target audience includes professionals.
>Maybe I'm an eternal optimist, but I don't think I'm being unreasonable.

As a professional programmer who sometimes reads DDJ, I don't
think so either.

FWIW, it was Schneier's publication of Blowfish in DDJ which
got me interested in real cryptography. (I'd previously played with
one or two trivial ciphers, which in retrospect don't really deserve
the title. OTOH the adversary in question was clueless, so in fact
they were arguably good enough!)

>And professionals know how to use the right tool for the job; they know
>how to re-use existing tools when there is a pre-existing tool that does
>the right thing.

You were right, you are an eternal optimist :-) The set of
professional programmers who understand security in general, let alone
crypto in particular, is a very small subset of the set of
professional programmers. As various persons more expert than me have
frequently pointed out, security in general and crypto in particular
is much harder than it looks. As a result of this, it is sadly not
uncommon for professional programmers (who are not security / crypto
specialists) to e.g. come across some small part of their project
which needs crypto, do no research, and eventually incorporate some
half-baked homebrew algorithm which a) eventually returns to haunt
them; and b) takes more effort to debug than it would've required to
use a real one instead.

> If "use SSL" is the right answer, I don't think we
>should pretend otherwise. It does professionals -- and the community --
>a disservice to encourage people to re-invent the wheel (poorly).

Agreed. It is also a disservice to encourage people to treat SSL as a
magic layer of fairy dust which somehow makes the problem go away,
without considering the issues of key management, trust chains etc.
which surround it; without all of this, SSL is slow DH. (I'm not
suggesting you do this, but it's a common failure mode.) Even with
the right tools, it's still hard to get it right!

In this non-ideal world, there may be scope for protocols which are
weaker than best practice, but are better understood by those who are
responsible for implementing them. In this case, the implementers will
hopefully be aware of the protocol's weaknesses, and so can take
suitable countermeasures of some kind within the wider context in
which the protocol is used.

In contrast, blindly using a best-practice black box may in fact be
less secure because its limitations are not understood. This can lead
to either a hazardous false sense of security ("we use SSL, therefore
we are invulnerable"), or a situation where the implementors
responsible for plumbing the black box into the wider application
inadvertently undermine it, by using it in a way which it wasn't
designed for.