gpg rejects SHA224 with DSA-2048

[David Shaw]

On Nov 9, 2009, at 8:20 AM, Kevin Kammer wrote:

> On Mon, Nov 09, 2009 at 11:52:48AM +0100 Also sprach Werner Koch:
>> On Mon,  9 Nov 2009 04:17, rjh at sixdemonbag.org said:
>>
>>> When did this changeover take place, and is there any way to get  
>>> the old
>>> behavior back?
>>
>> On 2009-07-09; that is since 1.4.10 / 2.0.13.  There is no option to
>> change it back.  The code in g10/keygen.c reads:
>>
>>    /*
>>      Figure out a q size based on the key size.  FIPS 180-3 says:
>>
>>      L = 1024, N = 160
>>      L = 2048, N = 224
>>      L = 2048, N = 256
>>      L = 3072, N = 256
>>
>>      2048/256 is an odd pair since there is also a 2048/224 and
>>      3072/256.  Matching sizes is not a very exact science.
>>
>>      We'll do 256 qbits for nbits over 2047, 224 for nbits over 1024
>>      but less than 2048, and 160 for 1024 (DSA1).
>>    */
>>
>>    if(nbits>2047)
>>      qbits=256;
>>    else if(nbits>1024)
>>      qbits=224;
>>    else
>>      qbits=160;
>>
>
> I imagine it would not be terribly difficult to rewrite keygen.c to
> offer the option of qbits=224 for nbits==2048, offered at key  
> generation
> time (likely with the --expert flag set), but it would be a non- 
> trivial
> change for a very questionable benefit.

Very questionable, indeed.  There are a number of places where the  
various standards that comprise OpenPGP, and the OpenPGP standard  
itself, give the implementor leeway to pick path A or B.  Each  
additional line of code to implement changes to accommodate stuff like  
this adds testing time, adds potential for bugs, and takes away time  
from more useful things.  IT department rules don't always make sense,  
but you can't make a product like GPG in constant fear that some  
hypothetical IT department will take offense at some particular  
obscure detail in it (a detail, again, that is correct as per the DSS  
and OpenPGP specs).  If that IT department became non-hypothetical, it  
might be worth looking at.

In any event, that hypothetical IT department will find it rather hard  
to use OpenPGP at all - offhand, I can't think of any current OpenPGP  
product that supports DSA over 1024 bits that doesn't use a 256-bit q  
for a 2048-bit key.

David