[2367] in cryptography@c2.net mail archive
Re: Weak Crypto and Y2K
daemon@ATHENA.MIT.EDU (Rick Smith)
Wed Mar 25 15:06:43 1998
In-Reply-To: <v03130301b13e913900de@[24.128.40.70]>
Date: Wed, 25 Mar 1998 11:58:08 -0600
To: "Arnold G. Reinhold" <reinhold@world.std.com>,
Nathan Spande <nathan@epicsys.com>,
"'perry@piermont.com'" <perry@piermont.com>
From: Rick Smith <rsmith@securecomputing.com>
Cc: "'cryptography@c2.net'" <cryptography@c2.net>
At 8:36 AM -0500 3/25/98, Arnold G. Reinhold wrote:
>I think there is a parallel between designing electronic commerce
>infrastructure today that use weak cryptography (i.e. 40 or 56 bit keys)
>and, say, designing air traffic control systems in the '60s using two
>digit year fields. You know it will work well enough for now, but that it
>will certainly be a problem in the future. Yes, there are other weak points
>that will have to be addressed, but that is no excuse for employing
>crippled technologies. Just because you can retire before it all blows up
>doesn't make it any less irresponsible.
Let us not accuse engineers of being "irresponsible" because they failed to
predict an uncertain future. The whole point of engineering design is to
make sensible trade offs between what is known for certain about design
objectives, component costs, and anticipated design life. If the device
exceeds its design life, it's more of a tribute to capable work than an
indication of incompetence. If you found yourself in the shoes of that '60s
engineer you probably would have made the same design decisions for the
same reasons, or perhaps you would have ended up with an inferior overall
result.
Regarding the use of 40-bit keys, it's essential to keep in mind that
nobody's recommending the technology on its own merits. It wouldn't get a
mention if it wasn't for the coercive effects of export regulations, and
their interaction with the costs of software product development. And, as
you're no doubt aware, 40 bit keys aren't the only "crippled" technologies
we use as far as security is concerned. Let's not even get started about
our favorite server packages or the OS platforms we generally rely on: Unix
and NT.
Responsibility consists of helping people understand the strengths and
limitations of the technology they use. It's far less responsible to say
"it's got 128 bit encryption keys, so it's completely safe." If customers
decide it's in their best interest to take the risks of weaker crypto, as
well as the risks inherent in commercial server technology, then it's not
our place to stop them.
If we think it *is* our place, then we've swallowed NSA's cant about the
need for some Big Brother to mediate personal crypto use: "I'm not going to
let you use that. It's for your own good." Puhleeze.
Personally, I think the general public has a lot to learn about proper
crypto use, and they'll only learn through experience. The sooner they
start (even if stuck with a 40 bit encryption key length for now) the
sooner they'll understand it and use it effectively. And then crypto key
length just might become a grass roots political issue like gun control.
Meanwhile, the "irresponsible" thing to do is to hardwire either the
algorithm or the key length into your application. Fortunately, state of
the art applications make this a configurable feature.
Rick.
smith@securecomputing.com
