general defensive crypto coding principles

[Jack Lloyd]

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