[ISN] Subject: linux-ipsec: Re: 1des inclusion NOT!

From: mea culpa (jerichoat_private)
Date: Mon Feb 08 1999 - 12:18:26 PST

  • Next message: mea culpa: "[ISN] Open letter to hacking community (from Penenberg/Forbes)"

    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