general defensive crypto coding principles

[Peter Gutmann]

Jack Lloyd <lloyd at randombit.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 majordomo at metzdowd.com