[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",
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