ietf-openpgp
[Top] [All Lists]

Bigger DSA keys

2005-09-16 16:00:57

I have it on good authority that NIST will be announcing larger size
DSS keys soon.  According to my source, the date will be by the end
of October.

Currently, DSS keys have two problems.  First, they can be no bigger
than 1024 bits.  Recent results show that keys of this size can no
longer be considered safe from large scale attackers.  See for example
http://lists.virus.org/cryptography-0509/msg00080.html (although this
is for RSA keys, DSS keys of a similar size are not thought to be too
much more difficult).  Second, DSS keys are locked into using SHA-1,
for which attacks have been published.

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.

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.

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.

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.

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.

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.

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.

Hal Finney

<Prev in Thread] Current Thread [Next in Thread>