[cryptography] preventing protocol failings

Steven Bellovin smb at cs.columbia.edu
Tue Jul 5 12:09:23 EDT 2011


> there may be a pragmatic need for options dealing with existing
> systems or business requirements, however i have yet to hear a
> convincing argument for why options are necessary in any new system
> where you're able to apply lessons learned from past mistakes.

You said it yourself: different businesses have different requirements.
The requirements may be operational environment or they may be
marketing-related.  I'll give just one example: web authentication.
If, say, I'm building a web-based interface to a system for tasking
an orbital COMSAT satellite.  That system should likely require
strong role-based authentication, possibly coupled with authentication
of the machine it's coming from, plus personal authentication for
later auditing.  By contrast, an airline reservation system that's
used for selecting seats (and printing boarding passes) will frequently
be used at hotel and airport kiosks, may be delegated to administrative
assistants, etc.  At some level, it's the same problem -- reserving
a resource (surveillance slot or an airplane seat), but the underlying
needs are very different.

More importantly (and to pick a less extreme scenario), security isn't
an absolute, it's a matter of economics.  If the resource you're
protecting isn't worth much, why should you spend a lot?  There are
certainly kinds of security that cost very little (RC4-128 has exactly
the same run-time overhead as RC4-40, though the cost of the public
key operations commensurate with those key lengths will differ);
other times, though, requirements are just plain different.

To quote the old Einstein line, a system should be as simple as possible
but no simpler.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb








More information about the cryptography mailing list