gpg rejects SHA224 with DSA-2048

[David Shaw]

On Nov 7, 2009, at 10:24 PM, Kevin Kammer wrote:

> On Sat, Nov 07, 2009 at 09:44:23PM -0500
> Also sprach Robert J. Hansen:
>> Kevin Kammer wrote:
>>> If I attempt to create a data signature using a 2048-bit DSA signing
>>> key, and the SHA224 hash algorithm, GnuPG complains as follows:
>>>
>>> ~ $ gpg -u A39CE7E5 --digest-algo H11 -b test.txt
>>
>> Your key is not on the keyserver network, so that will impair our
>> ability to help you out with this.
>>
>> It appears that your key is actually 14CA0E78.  To tell it to use a
>> particular subkey, you need to append a "!" to the subkey ID.
>> Otherwise, I believe GnuPG's behavior is to look at the certificate  
>> that
>> subkey belongs to, and use the largest signing subkey on that
>> certificate.  If you have a 3072-bit signing subkey on 14CA0E78, this
>> would explain your problem.
>>
>> Try:
>>
>> ~ $ gpg -u A39CE7E5! --digest-algo H11 -b test.txt
>>
>>
>
> My fault for not including the complete shell output from the command,
> but GnuPG does indicate that it is using 2048-bit subkey A39CE7E5.
>
> I had already tried it with "!" just to be sure, but the result was  
> the
> same, as is the result of attempting this with a 2048-bit primary key.
>
> Regardless of whether it is a sub-key or a primary, GnuPG just seems  
> to
> mandate the use of SHA256 with 2048-bit DSA. This is not necessarily a
> bad thing, but it is not "by the book," so I am trying to ascertain  
> why.

That's not quite how it works.  What matters here is how the key was  
generated in the first place.

One of the numbers used to generate a DSA key is known as "q".  In  
DSA, the size of q is what controls the size of the hash that will be  
used with the key.  This value is set at key generation time, and  
cannot be changed (it's part of the key).  It has no strong  
relationship to the overall key size, so in theory, you could have a  
2048-bit DSA key that uses a 8-bit hash.  Of course, that would make  
for pretty poor signatures, so the DSA spec (and OpenPGP spec in turn)  
give some guidelines as to what hashes should be used for a given key  
size.  For a 2048-bit key, you can choose either a 224 or 256 bit q.

So, let's say you had a 2048-bit key, and the program you used to  
generate it chose a 256-bit q size.  This key would allow a 256-bit  
hash.  A 224-bit hash is impossible (too small).  If you had a 2048- 
bit key and the program you used to generate it chose a 224-bit q  
size, this key would then allow a 224-bit hash.  A hash larger than  
224 bits is allowable as well, but would be truncated down to 224 bits  
to fit.

The problem you are having is that whatever program generated your key  
chose a 256-bit q size.  That parameter, chosen at key generation  
time, not GPG at signing time, is what is preventing you from using  
SHA-224.

So the real question here is why did your program generate a DSA key  
with a 256-bit q, when a 224-bit q would have been equally acceptable  
according to the spec?  As you say, they are both legal.  The answer  
there is that while both are legal, a 256-bit q is slightly stronger  
as it allows a larger hash to be used.  Both PGP and GPG use a 256-bit  
q for a 2048-bit key.  However, if you managed to generate a 2048-bit  
key with a 224-bit q (as earlier versions of GPG did), all versions of  
GPG would (correctly) allow the use of SHA-224 with this key.

David