Forwarded From: "Jay D. Dyson" <jdyson@techreports.jpl.nasa.gov>
Originally From: John Gilmore <gnu@toad.com>
Originally To: Linux IPsec <linux-ipsec@clinet.fi>, gnu@toad.com
People have been bandying about various claims about the security of
various ciphers. My own point of view is that none of the ciphers
mentioned (things like RCn, Blowfish, and various AES candidates) has had
the substantial investment in *understanding* its real security that DES
has had. You can't prove that an algorithm is secure; you can only prove
that it's insecure (by cracking it). It took more than fifteen years
before any theoretical cracks of DES were published, and longer than that
before the first public brute-force attack. Blithe statements like "X is
more secure than DES" have no basis in fact. In three years we'll know
much more about the security of the leading AES candidate, though we
probably will not be able to say for certain that it is "more secure than
DES". Today we only know useful facts about the security of *some* of the
AES candidates -- the ones that have already cracked. Due to the way
unmodified single DES is used as a subcomponent, it is strongly believed
that 3DES is no less secure than DES -- but we know little more than that
about its true security.
One thing we *can* measure relatively accurately is the speed of various
algorithms, leading people to want to compare them on that basis. I truly
see the speed of all these ciphers as irrelevant in the short, medium, and
long term. 3DES IPSEC already maxes out a T1 line using ordinary PC
processors from a year or two ago. If you really want to secure a T3,
fine, buy a hardware 3DES board; you're .005% of the market. If you want
to use ten-year-old hardware to secure your T1 line, get a life and spend
$500 for this year's low-end PC.
We're laying the keel for the privacy of all Internet traffic. As this
protocol moves into the firmware and circuitry of future generations of
devices, which algorithms we pick will be irrelevant to the cost or price
of the devices. But which algorithms we pick will be VERY relevant to the
privacy of the traffic.
Turn off and leave off all algorithms except 3DES in your Web browser, and
see how many "secure" sites are unable to talk to you. It's more than 0%,
years after 3DES servers came out. If we start off by making IPSEC
compatible with insecure algorithms, some fraction of the net will end up
using them forever. That fraction may be quite large if NSA pressures a
few mass-market companies into "neglecting" to implement stronger
algorithms (using export controls or private deals). It'll be much harder
for anyone to get away with this if the lobotomized IPSECs won't actually
interoperate with real IPSECs.
Pardon my "French" here, I get emotional on this issue. I put a year into
building a fucking brute-force cryptanalysis machine to make it 1000%
clear that single DES is useless, and some of you bozos still don't get
it. If there is any easy way to make any code that I'm involved with
interoperate with single DES, or with any unproven cipher, I consider that
a major bug. This is not going to be a smorgasbord feature-checklist
product, it's a plug-in-and-turn-on privacy product. (It's hard enough to
build in real security with NO options.) If you don't like it, nobody's
forcing you to use Linux or the Linux IPSEC implementation; buy one from a
vendor who doesn't care about privacy. You can have insecurity or you can
use this code, but I will work hard to make sure you don't get both in the
same package.
John Gilmore
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
Received on Thu Mar 11 17:20:26 1999