Re: NIST publishes new DSA draft

Jon Callas <jon@callas.org> Mon, 27 March 2006 21:49 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNzaP-0005dm-4L for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:49:17 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNzaO-0005KL-Bf for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 16:49:17 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLSLjF018913; Mon, 27 Mar 2006 14:28:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2RLSLKR018909; Mon, 27 Mar 2006 14:28:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RLSKgR018888 for <ietf-openpgp@imc.org>; Mon, 27 Mar 2006 14:28:20 -0700 (MST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for <ietf-openpgp@imc.org>; Mon, 27 Mar 2006 13:28:14 -0800
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 27 Mar 2006 13:28:14 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 27 Mar 2006 13:28:14 -0800
Mime-Version: 1.0 (Apple Message framework v746.3)
In-Reply-To: <44284CDB.9040504@algroup.co.uk>
References: <20060314194447.4D59A57FB0@finney.org> <20060316192823.GA9945@jabberwocky.com> <441ACF45.704@systemics.com> <87fylhdq36.fsf@wheatstone.g10code.de> <20060317174937.GC13241@jabberwocky.com> <3C3EAEDD-7724-4E92-AA3C-49B5B2E6F3F9@callas.org> <44267719.1060302@algroup.co.uk> <C6620F59-F7F1-498E-B999-9BB08715395F@callas.org> <44284CDB.9040504@algroup.co.uk>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <494A8BEE-97D3-4B31-92C3-D67A645D8EE0@callas.org>
Content-Transfer-Encoding: 7bit
From: Jon Callas <jon@callas.org>
Subject: Re: NIST publishes new DSA draft
Date: Mon, 27 Mar 2006 13:28:13 -0800
To: OpenPGP <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.746.3)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a


On 27 Mar 2006, at 12:36 PM, Ben Laurie wrote:

>
> I'm not going to argue with this, but it clearly ain't much more. You
> would be out on a limb to argue that it provided usefully more than  
> 112
> bits - though I won't hesitate to agree that 2DES < 3DES.
>

Ben, I think we're far closer to agreeing than disagreeing.

During The Crypto Wars, we crypto-proponents made a point of saying  
that the minimum crypto we'd live with was 128-bit. The reasons for  
this had as much to do with the simple mathematical fact that 128 was  
the next convenient power of two as anything else. So therefore, viva  
IDEA, viva CAST, viva Blowfish. A lot of it was also just sheer  
politics.

But what about three-key 3DES? Collectively, we agreed to include it  
as a "128-bit" cipher (the quotes are there to mean quasi-, or so- 
called). The reasons for this were also mostly politics. It would  
have been unwise to say, "ooo, ick, 3DES" and in fact in this group,  
arguably the most political standards group of them all, we not only  
*accepted* 3DES as 128-bit cipher, but made it the MUST. That was  
also mostly a political decision. It saved us a long, acrimonious  
argument about Blowfish and CAST with side trips along 3DES itself,  
DES/X, SAFER and others. Bravi us. (Personally, I say "3DES" to mean  
three-key-3DES. I consider the two-key version to be some unmentioned  
step-down, kinda the way that Blowfish will work with 32-bit keys.  
It's true, but we don't even grace it with a mention.) Reality is a  
collective hunch, especially in the IETF. The hunch is that 3DES is  
as good as IDEA, CAST, Blowfish, etc.

Now, a decade later, we all mostly use AES. In fact, we mostly use  
AES-256, and that for marketing reasons. AES-128 runs faster than  
single-DES, and AES-256 is only 20% slower than -128, so there is  
pressure to step up to 256-bit keys. People do it because all the  
other kids are doing it, not for security.

You are right that we've *agreed* that 3DES is a "128"-bit algorithm  
and there's no math to back it up. As fantasies (or collective  
hunches) go, it's not a bad one. The strength of 3DES all revolves  
around how much it's not a group. It appears to be enough of a non- 
group that this isn't a mad thought. Better, though, to just use AES.  
Or Twofish. Or petition the group to put Serpent in.

Nonetheless, getting back to the hash functions, the *only* reason to  
use SHA-224 is that you have an application where a 28-byte hash will  
work and a 32-byte one will not. If one person thinks that's  
important for engineering reasons, I'm happy to have it in. If zero  
people think it has engineering value, then less is more. We don't  
need another hash function with no obvious value because in the  
future there will be more hash functions. Save room on the bus for  
the ones that aren't born yet.

	Jon