Re: NIST publishes new DSA draft

[hal@xxxxxxxxxx ("Hal Finney")]

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