general defensive crypto coding principles

Jack Lloyd <lloydrandombit.net> writes:
>On Fri, Feb 10, 2006 at 07:21:05PM +1300, Peter Gutmann
wrote:
>> Well, that's the exact problem that I pointed out
in my previous message - in
>> order to get this right, people have to read the
mind of the paper author to
>> divine their intent.  Since the consumers of the
material in the paper
>> generally won't be expert cryptographers (or even
inexpert cryptographers,
>> they'll be programmers), the result is a disaster
waiting to happen.
>
>I would expect that typically implementors would be
following a published
>standard, which would (well, one would hope) have had
expert cryptographers
>check it over sometime prior to publication

Unfortunately that doesn't work in the real world for two
reasons:

1. There are a great many special-case situations where no
published protocol
   fits.  As the author of a crypto toolkit, I could give
you a list as long
   as your arm of user situations where no existing protocol
can be applied
   (I'd prefer not to, because it's a lot of typing).  The
reason why existing
   protocols don't fit isn't because they're deficient in
some way, but
   because there are so many specialised applications where
security is needed
   that it isn't really possible to accomodate all of them
in a single, or
   small set of, protocols - sometimes you have to do a
custom design.

2. Published standards, at least IETF and ISO ones, don't
include any
   rationale, and usually don't include implementation
guidance either (this
   is a pet peeve of mine).  Sometimes they don't even
include critical
   security-related information.  There was one wonderful
example in IPsec
   where a major implementation got some feature that the
spec never bothered
   to specify wrong.  In the absence of any guidance in the
spec, there was a
   50:50 chance of doing it wrong, and this particular
implementation happened
   to have the coin fall the wrong way when they were
deciding on what to do.
   When asked about why the spec never specified how to
handle this, one of
   its authors replied that this was a well known problem
and everyone should
   know what to do.  So implementors were expected to read
the authors' minds
   to get it right.

So saying it's a simple case of waving an expert
cryptographer over the
problem doesn't really work.  There's a wonderful quote
about this approach by
Marv Schaefer, "to get a truly secure system, you must
ensure that it's
designed and built by geniuses.  Unfortunately, geniuses are
in short supply".
It's better to design a system that can be used by the
average user than one
that's brittle enough that only geniuses can safely employ
it.

Peter.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On Tue, Feb 14, 2006 at 03:24:09AM +1300, Peter Gutmann
wrote:

> 1. There are a great many special-case situations where
no published protocol
>    fits.  As the author of a crypto toolkit, I could
give you a list as long
>    as your arm of user situations where no existing
protocol can be applied
>    (I'd prefer not to, because it's a lot of typing).
[...]

I'm also the author of a crypto toolkit, and I'll admit
I've been involved in
creating custom security protocols more than once myself.
I'm well aware that
this is a legitimate need.

> It's better to design a system that can be used by the
average user than one
> that's brittle enough that only geniuses can safely
employ it.

I think the source of our different views on this is a
result of expectations
with regards to what your average programmer is capable of
in terms of secure
protocol design. I have done reviews on probably a dozen or
so products that
had a custom crypto component of one sort or another, and
there were often
really trivial problems (typically the well-known and
well-documented ones that
people have been getting wrong for decades).

At this point I'm generally of the opinion that there are
maybe 5% of
programmers who will be careful enough to get it right, and
the rest will get
it spectacularly wrong because they won't bother to do
anything more than
perhaps skim Applied Cryptography. So, if you're going to
mandate just one
technique for everyone, you're better off (IMO) using
something that is a bit
trickier but has better optimal bounds, because the 5% will
still probably get
it right (and their protocols will be better off for it) and
the rest are too
busy getting it wrong in other ways to bother implementing
the authenticated
encryption mode incorrectly.

In short, I find it extremely optimistic to think that there
is any substantial
population of programmers who could correctly design and
implement a
non-trivial and secure crypto protocol without taking a
reasonable amount of
time with the existing body of knowledge.

-J

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com