Forwarded From: "Jay D. Dyson" <jdysonat_private> Originally From: John Gilmore <gnuat_private> Originally To: Linux IPsec <linux-ipsecat_private>, gnuat_private 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 majordomoat_private with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:18:22 PDT