Are DSA2 signing keys backwards compatible?

Robert J. Hansen rjh at sixdemonbag.org
Mon Feb 11 16:30:57 CET 2008


Kevin Hilton wrote:
> My reason for asking these questions is in regards to a documentation
> Im trying to compose for a user's group.

If you are interested, I have about half of a GnuPG user's manual
written up in DocBook format.  Right now it only covers the mathematical
and conceptual side of GnuPG, leaving a lot of practical stuff to be
done, but it may be useful to you.

> Its clear to me you are following both the FIPS and OpenGPG RFC 8440
> in implementing the program

4880, not 2440.

> however the truncation of longer hash products ... is very troubling
> and extremely difficult to document

RFC4880 documents the truncation process pretty well: leftmost bits
only, etc.  The truncation process itself should not be troubling.  Any
set of bits could be truncated--high order, low order, high-order even
bits, low-order odd bits, bit positions that lie along a Riemann zeta, etc.

A hash should be indistinguishable from noise.  Any selection from noise
is just as random as any other selection.

Hash truncation is very well documented within the field of cryptography
and cryptanalysis.  If you like, check the _Handbook of Applied
Cryptography_, which is available for free online or in dead-tree form
from any decent university library.

> Given the above example (just one example), where a 3072 DSA key
> actually uses either a SHA256 or SHA512 bit hash (truncated to 256
> bits), despite what is listed when showprefs is displayed -- How do
> you actually document this scenario?

Showprefs is a hint to GnuPG, not an absolute rule.  GnuPG is within its
rights to reject a preference if GnuPG determines that the preference is
irrelevant to a particular environment.  Document that DSA1024 requires
a 160-bit hash and thus any preference for MD5 will be ignored, DSA2048
requires a 224-bit hash and thus any pref for MD5, SHA1 or RIPEMD160
will be ignored, DSA3072 requires a 256-bit hash and thus any pref for
MD5, SHA1, RIPEMD160 or SHA224 will be ignored.

> Are RSA signing keys subject to some of the same nuances as DSA keys?
> Practically could a 1024 bit RSA key be used with a 512 hash?

RSA signing keys may be used with any length of hash.  I think this is
probably a misfeature, but it is what it is.

People have this really annoying habit of believing GnuPG needs to be
tweaked to get good communications security.  It leads people to doing
things like generating a 1024-bit RSA signing key since that's all that
will fit on their smartcard, but using SHA512 as a hash algorithm to try
and 'compensate' for their short RSA signing key.  Just as ridiculous,
IMO, is the conventional wisdom that symmetric key lengths, asymmetric
key lengths and hash lengths should all be 'balanced'.  Etc., etc.

Hence, as you've remarked, my usual curt recommendation to stick with
the defaults and not worry about it.





More information about the Gnupg-users mailing list