Hal Finney wrote:
The new DSS keys will, according to what I have heard, be for two sizes:
2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively.
(SHA-224 is not presently an OpenPGP algorithm; it is basically a
truncated version of SHA-256 with a different internal initial value).
This will allow for larger keys and use a different hash than SHA-1.
(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.)
If this report is correct, it would be good to see these new key sizes
in RFC2440bis. Otherwise the DSS support in the spec will be essentially
"dead on arrival". Rather than publishing a spec with a major class
of keys that has no future utility, I think it makes sense to wait six
weeks and see if we can incorporate the new information, making the
spec much more robust and long-lasting.
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.
Which rambling means to say that even after the October
date, I suspect it will be all too easy to say "let's
wait a bit more..."
For those who say we have waited too long already, I will just note that
the weeks and months drift by without much reason for delay but without
much progress either. Now that there is a good reason to hold off a
bit more, I would hate to see us suddenly rush to close the door.
One issue is how best to incorporate these new key sizes. As I see it,
there are three alternatives.
1. Just use the new sizes with the existing DSA keys. Instead of only
512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the
proper hash algorithms in software.
2. Use a new algorithm ID for the new DSA keys, which would be only
for 2048 and 3072 bits. The old algorithm ID would continue to be
used for old DSA keys.
I think I'd lean towards this one. This would allow
us to deprecate DSA-old just as soon as we can.
3. Use a new key packet version number for the new DSA keys, V5.
Perhaps V5 keys could use a SHA-256 based fingerprint. This would
represent a clean break from the old way.
I'd go against this (for the same reason you
outline below).
The first alternative would involve the least change to the spec, just
changes to the information about how to sign and verify with DSA keys.
The second alternative would require adding much the same material
but with the handling of the new algorithm ID called out separately.
It would probably duplicate some of the information on old-style DSA keys.
Ah, good point. But unless by some miracle all the
implementations can handle #1 without blowing up,
then I can't see how we'd countenance an incompatible
change?
The third alternative is the most ambitious and is not feasible for
RFC2440bis IMO. We could still go to a V5 key packet at some point in
the future anyway, and perhaps do other improvements at that time.
Right.
Between the first two, I would propose to decide largely on the basis of
backwards compatibility. Obviously signatures made with new-style DSA
keys will not be verifiable in old code. The question is how gracefully
existing implementations will fail when presented with such keys and
signatures, in either the first or second form. Testing on current
implementations could provide guidance as to which way of making the
change will cause the least trouble.
Certainly interesting times for DSS fans. I use it
in a lot of my stuff and have pretty much made up my
mind to move to RSA when and as I can. Mostly this
is because NIST have moved too little, too late on
this one, and the numbers above are already looking
like we'll be into a change again in about 2-3 years
when the new Hash research settles into a new generation
of algorithms.
iang