Re: Suggested changes for DSA2

[David Shaw <[e-mail]>]

On Tue, Mar 28, 2006 at 01:04:12PM -0800, "Hal Finney" wrote:

> I support David's suggestion to include a SHOULD relating hash size to key
> size.  But it makes sense to me to extend our current key size SHOULD
> recommendations to include advice regarding subgroup size, hash size,
> and symmetric cipher key size.  This would correspond to Table 2 on page
> 63 of NIST's SP800-57:
> http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf
> 
> The sizes from that table are:
> 
>  1024 /  160 /  80
>  2048 /  224 / 112
>  3072 /  512 / 256
>  7680 /  768 / 384
> 15360 / 1024 / 512
> 
> where the 1st column is the RSA, DSA or DH modulus size, the second
> column is the hash/subgroup size, and the 3rd column is the symmetric
> cipher key size (which is also the strength in bits).

Are you sure that table is correct?  I thought it was:

  1024 / 160 /  80
  2048 / 224 / 112
  3072 / 256 / 128
  7680 / 384 / 192
 15360 / 512 / 256

> Proposed language:
> 
>    In order to provide consistent levels of security for end users,
>    implementors SHOULD balance public key modulus size, subgroup size,
>    hash size, and symmetric algorithm key size.  While consensus about
>    appropriate choices of these parameters may change with time, NIST
>    Special Publication 800-57 recommends the following parameter size
>    choices:
> 
>    [Some version of NIST's Table 2 here]
> 
>    Implementors SHOULD use and require public key and other parameters
>    consistent with values in this table, or updated information based
>    on evolving consensus in the field.

I'm not sure this is the right way to go about it.  Is balance
actually what we want, or would it be better to just remind people
that the weakest parameter constrains the level of security?  There is
nothing invalid about a 8192-bit RSA key making SHA-1 signatures.  It
just means that the signature has at most 80 bits of strength.  The
signer could have used a 1024-bit RSA key and gotten the same 80 bits
of strength, but that doesn't make the 8192-bit signature wrong (just
large).  My suggested wording was more to encourage implementors to
indicate the actual strength, rather than to force balance.

How about this (presumably for the Security Considerations section):

   As OpenPGP combines many different asymmetric, symmetric, and hash
   algorithms, each with different measures of strength, care should
   be taken that the weakest element of an OpenPGP message is still
   sufficiently strong for the purpose at hand.  Implementations
   receiving messages SHOULD indicate to the user the actual strength
   of the messages.  While consensus about the the strength of a given
   algorithm may evolve, at publication time, NIST Special Publication
   800-57 [SP800-57] recommended the following list of equivalent
   strengths:

       [ put table here ]

I'm still in favor of making the NIST list a SHOULD for generating
DSA2 keys, of course.

David