[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bigger DSA keys

Ian Grigg writes:
> (assuming we do it,) I would suggest we ditch the 2048/224
> and just implement the 3072/256.
> (We could add the other one as a MAY ... but I can't see
> the point of it.  Sure NIST may split hairs on it, but
> let's save ourselves the doco and the discussion and
> just do the better one.)
> ...
> I don't think it is that easy.  SHAs are under a cloud,
> and until we get some more definitive info on the new
> hardware factoring, even the numbers suggested above
> won't satisfy all the extremists.  Consider that the
> extreme community considers 4096 to be a minimum, and
> all the news is supporting them at the moment;  also,
> NIST's hash work has been controversial (SHA0, SHA2
> being just an "extension" ...), I'd like to see what
> the crypto community comes up with in hash research as
> that feeds into DSS.

I'm not sure why there is not a plan for larger key sizes.  A possible
clue is in this NIST document, "Recommendation for Key Management",
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf .
Table 2 on page 63 shows the following correspondences between hash size
and modulus size: 160/1024; 224/2048; 256/3072; 384/7680; and 512/15360.

This fits what we know, with SHA-1 and a 1024 bit modulus as the
traditional DSS; SHA-224 and a 2048 bit modulus, and SHA-256 and a 3072
bit modulus in this new DSS that I have been told about.  It implies that
the natural next size would be SHA-384 and a 7680 bit modulus.  But that
modulus is too big for most people's convenience.

You might say, just use SHA-384 and a 4096 bit modulus, but that is not
such a nice fit.  The hash is a lot stronger than the modulus and so it
is not well balanced.  Perhaps such esthetic considerations motivated
NIST's decision.

Hal Finney