Re: Suggested changes for DSA2

[David Shaw <[e-mail]>]

On Mon, Mar 27, 2006 at 03:22:15PM -0800, "Hal Finney" wrote:
> David writes:
> > For implementation of signature verification you can just take p and q
> > straight from the public key.  You don't need to guess since the key
> > has all the information you need.
> 
> With signatures, it is the verifier more than the signer who is vulnerable
> and who needs to be protected.  The problem is that as the verifying
> software it is my responsibility to provide some level of assurance to
> the user about how strong this signature is.
> 
> Right now at best we only report the key size.  I'd like to make sure that
> q is as strong as p.  Otherwise we might see a 4096 bit key with a 160 bit
> q, so it is really no stronger than a 1024 bit key.  It is hard to report
> to the user how strong a signature by that key should be considered to be.
> 
> This problem goes away if we standardize on the q sizes that go with
> certain p sizes.  That's what I'd like to do.  Any keys that break the
> rules would be considered invalid.  Maybe we don't have to just do the
> FIPS ones but could extend them somewhat.

Forgetting DSA2 for a moment, this isn't a new problem.  We have this
same key size / hash size mismatch possibility today with DSA1 (since
DSA in 2440 could be 768-1024 bits), and again with RSA (which can use
any hash, regardless of the key size).  Fixing the q sizes for DSA2
doesn't really solve this.

I do agree there is an issue here, but I have trouble seeing it in
terms of something that can be fixed in the standard, especially in a
reasonably future-proofed way.  It just feels a bit like pushing a
user or UI problem into the data specification.

Implementations are free to use whatever guidelines they like in
presenting signature information to the user.  It would be very
reasonable for a program to pop up some sort of "Warning: the hash
used in this signature is weaker than the key", or "this signature has
xxxx bits of assurance" or whatever sort of message is deemed most
understandable.  I just think that the onus is on the implementation
to do this, and not the standard.

That said, I would support language (perhaps in the Security
Considerations or signature sections) that read something like this:

   When verifying a signature, it may be noted that the strength of
   the signing key and the strength of the hash used are not similar.
   In such cases, implementations MAY/SHOULD warn the user that the
   overall signature strength is limited by the weakest part.  In
   extreme cases, the implementation may wish to consider the
   signature to be in error.  While conventional wisdom may change
   over time as to the strength of algorithms, at publication time,
   one such set of guidelines is [SP800].

And add a cite for [SP800] to the NIST key length / hash length guide.

David