Subject: Re: NIST publishes new DSA draft

From: [email-masked] ("Hal Finney")
Date: Thu, 16 Mar 2006 12:19:51 -0800 (PST)

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

---

From: David Shaw <[email-masked]>
Date: Thu, 16 Mar 2006 15:51:02 -0500

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

Absolutely.  I'm in favor of SHOULD.  This implies that DSA with
160-bit q is a MUST (as it is now), and DSA with >160-bit q is not a
MUST (though an implementation must at least know that DSA might have
a larger q and not blow up).

> see this as the preferable strategy.

While I agree that the bottom line is that the old code won't work and
the new code will, using a different algorithm ID potentially gives a
better (and more user-comprehensible) error than using the same
algorithm ID does when the old code doesn't work.  That is to say, it
may fail "prettier" (it does in the GPG case).  I don't think it's
that big of a deal, and I'm not arguing for it.

On a related issue, do you think a feature flag to indicate the
ability to handle a truncated hash would be a good idea?  I'm leaning
towards no, as it would only be really useful in the sign+encrypt case
(where the implementation knows who the recipient(s) are and can thus
consult feature flags), but perhaps that's enough to justify it.

David