Peter Gutmann, pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz, writes:
Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com> writes:
At 10:50 AM 12/04/1997, Peter Gutmann wrote:
DSS/DSA is only specified for key lengths between 512 and 1024, but
OpenPGP
should be free to do longer keys, even though the standard doesn't
actually
support them.
There's no point in moving to p > 1K bits if q is only 160 bits because
it'll
be vulnerable to a small-exponent attack. Since q is governed by the hash
function associated with DSA, you then need to define a new hash function
wit
a larger output block size, and suddenly things get very messy. At the
momen
I don't think it's sensible to use keys > 1K bits, all it'll do is lead to
confusion about the amount of security offered.
Also, as I look at PGP key generation again, it does limit the DSA keys to
1024 bits, even when you're doing longer ElGamal. Doesn't necessarily have
to
do that, but I didn't find a way to input different behaviour.
To get around this, you could use Elgamal for signatures (although the
current
PGP doesn't support this, the code is commented out). I published an Elgamal
profile for X.509 a few months ago (available from RFC draft repositories)
which specifies how to do this and covers various security issues.
It's still questionable to go to longer key sizes even with ElGamal.
A birthday attack against the hash function has the same work factor as
breaking a 1024 discrete log, approximately (which is why DSS used the
160 bit / 1024 bit structure). Now for some apps a birthday attack is not
good enough, you need to duplicate the hash, which takes the square of
the effort, and for them using a longer key could work. But for general
use there is no point in increasing key size until you have a larger hash.
Anybody have a good way to synthesize a 320 bit hash out of a 160 bit one?
I found a paper which suggested doing a "butterfly" using 8 instances of
the smaller hash which looked pretty good (Eurocrypt 96, Aiello).
Hal