Are DSA2 signing keys backwards compatible?
David Shaw
dshaw at jabberwocky.com
Mon Feb 11 14:55:28 CET 2008
On Mon, Feb 11, 2008 at 07:31:43AM -0600, Kevin Hilton wrote:
> On Feb 10, 2008 10:53 PM, Kevin Hilton <kevhilton at gmail.com> wrote:
> > >You could use SHA-512 with
> > >it if you liked, but the hash would be truncated to 256 bits.
> >
> > Interesting. Are the higher or lower bits truncated?
> >
> > >We follow the advice in FIPS 180-3:
> > >
> > > L = 1024, N = 160
> > > L = 2048, N = 224
> > > L = 3072, N = 256
> >
> > Ok. So back to the ever asking defaults question, so why when I
> > produce a 3072 bit DSA signing key, why isnt my first digest hash
> > preference or choice SHA-256? Here is what I am getting:
> >
> > pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC
> > trust: unknown validity: unknown
> > sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E
> > [ unknown] (1). -----------------------------------------------------
> >
> > Command> showpref
> > [ unknown] (1). -----------------------------------------------------
> > Cipher: AES256, AES192, AES, CAST5, 3DES
> > Digest: SHA1, SHA256, RIPEMD160
> > Compression: ZLIB, BZIP2, ZIP, Uncompressed
> > Features: MDC, Keyserver no-modify
> >
> > It would seem in fact that my digest preferences should only be SHA256
> > or SHA512 based on the information provided! SHA1 or RIPEMD160
> > shouldn't even be listed here, correct?
> >
>
> My reason for asking these questions is in regards to a documentation
> Im trying to compose for a user's group. Obviously I'm very much a
> novice in both the mathematics beyonds GnuPG but in also its
> implementation. Its clear to me you are following both the FIPS and
> OpenGPG RFC 8440 in implementing the program, however the truncation
> of longer hash products, along with attempting to predict which hash
> the program based on the output available will actually use is very
> troubling and extremely difficult to document given all the nuances of
> the program, particularly in relation to DSA keys. 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?
First of all, leave out 'showpref' from your documentation of this
question as it has nothing at all to do with hash choice when you make
a signature. It's only relevant for other people making signatures
and sending them to you.
That leaves the question of which hashes are usable for a given DSA
key. The answer is that all DSA keys contain a number called the 'q'
value. That value specifies how large the hash must be when making
signatures with that key. There are a few differences, but the main
difference between DSA1 and DSA2 is that DSA1 keys have q=160 and it
cannot change. This is why DSA1 keys need SHA-1 or RIPEMD160 as their
hash: they are both 160-bit hashes, to match q=160. DSA2 keys can
have different q values.
In DSA2, you can use whatever hash you like as long as it is equal to,
or greater than your q size.
> 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?
Yes. It's silly, as the hash is vastly stronger than the key, but
it's legal, and GPG can do it.
> Again its all very confusing to me -- math aside and practical
> considerations why you wouldn't want to mix and match key types and
> hash lengths. Again Robert Hansen has wisely suggested use the
> defaults -- I'm understanding this more and more -- however when I see
> showpref statements that would suggest SHA-1 is the default hash, when
> in actuality with larger DSA keys it is not, I get rather frustrated.
Robert is quite right about the defaults. There are some very complex
issues here and GPG is a very configurable program. It's excellent
that people spend the time to understand the issues, but I find that
most people who spend the time to learn the issues also use the
defaults :)
Daxvid
More information about the Gnupg-users
mailing list