Re: NIST publishes new DSA draft

[David Shaw <dshaw@xxxxxxxxxxxxxxx>]

On Thu, Mar 16, 2006 at 12:19:51PM -0800, "Hal Finney" wrote:
> David Shaw writes:
> > 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?

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).

> 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.

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