Re: [TLS] Comparative cipher suite strengths

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 05 May 2009 03:26 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108EB3A69FC for <tls@core3.amsl.com>; Mon, 4 May 2009 20:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level:
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=-2.403, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtGG5XN2AgzW for <tls@core3.amsl.com>; Mon, 4 May 2009 20:26:09 -0700 (PDT)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id EB6EF3A6E3D for <tls@ietf.org>; Mon, 4 May 2009 20:25:43 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 8FC579FACD; Tue, 5 May 2009 15:26:57 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzt4x7eMkx7E; Tue, 5 May 2009 15:26:57 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7DD139FA12; Tue, 5 May 2009 15:26:56 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id F35E4E0808A; Tue, 5 May 2009 15:26:54 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1M1BJ0-0003em-Rp; Tue, 05 May 2009 15:26:54 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: tls@ietf.org, uri@ll.mit.edu
In-Reply-To: <C62333B9.44AA%uri@ll.mit.edu>
Message-Id: <E1M1BJ0-0003em-Rp@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@cs.auckland.ac.nz>
Date: Tue, 05 May 2009 15:26:54 +1200
Subject: Re: [TLS] Comparative cipher suite strengths
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2009 03:26:10 -0000

"Blumenthal, Uri" <uri@ll.mit.edu> writes:

>While this certainly makes a nice tea-table story, I question the "historical
>truthfulness" of it.

As I said, it was told to me by someone involved at the time, but it was some
years ago and unfortunately I didn't think to take names and numbers.

>YOU may need to explain things to YOUR customers (and make them understand),
>lest they feel mistreated and go to another vendor. I don't think USG
>agencies have the same luxury of choosing their own crypto policy provider
>and product approver!

You're assuming that the people in these organisations work like Turing
machines, and automatically follow all directives from a central authority.
Here's an instance of this kind of thing that happened to a large supplier to
the USG.  Some snake-oiler (it was either the JAWS L5 people or Meganet) were
trying to get their software adopted by this organisation.  They got a list of
contact details for people all over the organisation and called anyone they
thought would have any influence, all over the company (the person who had to
deal with some of the fallout described it as a kind of mongolian-hordes
attack, as soon as they'd stamped it out in one location it started up again
somewhere else), explaining that their algorithms were more secure because
they had bigger numbers behind the algorithm name.  This carried on for quite
some time, it was the same battle over and over again, and from the bits I
heard often came down to the security people having to say "drop this, or
else" because the target within the company didn't understand why they should
use prescribed algorithms when the snake oil was obviously better (it's quite
likely that some parts of the company, who were never discovered by the
security people, did end up using the snake oil).  You can see this (for
different organisations than the one above) with the occasional JAWS/Meganet
press release that some big customer (including USG users) have adopted their
stuff, try enough people in enough organisations and eventually they'll fall
for it, no matter how the Turing-machine model says they should react.
Meganet have even specifically targetted USG users via an active penetration
attack on FIPS 140, see their web site, complete with convenient GSA and CCR
links, for details.

Peter.