Re: NIST publishes new DSA draft ("Hal Finney") Thu, 16 March 2006 20:30 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FJz7N-0007sK-Ag for; Thu, 16 Mar 2006 15:30:45 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1FJz7M-0007uQ-US for; Thu, 16 Mar 2006 15:30:45 -0500
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id k2GKDkvg017500; Thu, 16 Mar 2006 13:13:46 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id k2GKDkek017499; Thu, 16 Mar 2006 13:13:46 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id k2GKDjiv017493 for <>; Thu, 16 Mar 2006 13:13:45 -0700 (MST) (envelope-from
Received: by (Postfix, from userid 500) id 3A87557FB0; Thu, 16 Mar 2006 12:19:51 -0800 (PST)
Subject: Re: NIST publishes new DSA draft
Message-Id: <>
Date: Thu, 16 Mar 2006 12:19:51 -0800
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

David Shaw writes:
> On Tue, Mar 14, 2006 at 11:44:47AM -0800, "Hal Finney" wrote:
> > We might want to think about making SHA-256 be another MUST algorithm.
> > The only MUST hash now is SHA-1.  Making SHA-256 be a MUST would make
> > these new key sizes be more useful, and also give us an easier fallback
> > if SHA-1 should be broken.
> Unless DSA2 is also a MUST, I wonder what the practical advantage to
> that would be (beyond making the social point that we really, really
> want people to move away from SHA-1).  Since an OpenPGP program would
> not necessarily know whether the recipient could handle SHA-256
> (SHA-256 dates from around 2004, implementation-wise), it would have
> to use SHA-1 in many or most cases anyway.  Obviously a DSA2 signature
> wouldn't be expected to work, but an RSA signature would have this
> problem, and DSA1 (using a truncated SHA-256) would have the problem
> as well for both truncation and SHA-256 reasons.

OK, but maybe a "SHOULD" like Werner suggested, then?

> A few months back you asked the question whether new DSAs would best
> be supported by extending the definition of the current DSA, or by
> assigning a new algorithm ID for DSA2.  At the time, most people
> (myself included) felt that extending the current DSA would be the
> right answer.  Now that we have actual information about DSA2, perhaps
> it would be worth revisiting that question.  A new algorithm ID for
> DSA2 resolves a number of problems in one fell swoop as there is no
> expectation of interoperability.  SHA-256 is always usable
> (effectively the default) for DSA2, and there is no problem with
> knowing when it is possible to use truncation (always).

At this point I like the idea of keeping the same algorithm ID.  All the
code and algorithms are the same, so using a different alg ID just
for different key sizes doesn't really make sense.  Using a different
algorithm ID will be, from the future perspective, a historical artifact.
And I don't see that it really helps interoperability to use a new ID.
Either way, the bottom line is that old code won't work with the new
keys and new code will.  Plus it makes implementation of the change a
lot easier - granted, a minor point, but on top of everything else I
see this as the preferable strategy.

> > I also think we should change the names of SHA256 etc to use dashes
> > as in SHA-256; those are the official names.
> To be clear here: are you referring to changing the descriptive text
> in the draft or changing the hash name strings as used in clearsigned
> message "Hash:" headers?  The first is easy and I agree should be
> done, the second has compatibility implications.

Just in the draft, then.  I guess we're stuck with the name strings.
It's not a big deal either way.

Hal Finney