gpg rejects SHA224 with DSA-2048

[Kevin Kammer]

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

...

2048-bit DSA key, ID A39CE7E5, created 2009-11-02 (main key ID 14CA0E78)

gpg: writing to `test.txt.asc'
gpg: DSA key A39CE7E5 requires a 256 bit or larger hash
gpg: signing failed: general error
~ $

However, RFC4880 and FIPS186 clearly state:

     ...that DSA be used in one of the following ways:

       ...

     * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
       hash

       ...

To the best of my knowledge, DSA with a 2048-bit key length only uses
224 bits of hash material. So, even if GnuPG insists that a 256 hash be
used, the digest is being truncated to 224 bits anyway.

While I realize that the SHA224 algo is essentially the SHA256 algo set
to spit out 224 bits--and therefore the difference between invoking
SHA224 vs. invoking SHA256 and truncating is essentially academic--it
still seems odd that GnuPG would reject SHA224 out of hand. If nothing
else, it does not seem to be in keeping with the OpenPGP standard.

Does anybody know why GnuPG rejects SHA224 with 2048-bit DSA signing
keys?

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Kevin Kammer]

On Sat, Nov 07, 2009 at 07:48:01PM -0500 I wrote:

> However, RFC4880 and FIPS186 clearly state:
>
>      ...that DSA be used in one of the following ways:
>
>        ...
>
>      * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
>        hash
>
>        ...
>

I should clarify that I understand the same specification goes on to
approve 2048-bit DSA with a 256-bit q, and I may have been mistaken in
believing that use of 2048-bit DSA will necessarily truncate the value
of q to 224 bits (perhaps someone could enlighten me as to whether or
not this happens).

In either case, however, the OpenPGP standard does specify that SHA224
can be used with 2048-bit DSA. So, my question as to why GnuPG refuses
that combination still stands.

My guess is that perhaps since there is no real advantage to using
SHA224 when SHA256 is available, it is simply not implemented. But I
would appreciate it if someone with more knowledge were to give me an
authoritative answer.

Thanks,
Kevin

--
"Le hasard favorise l'esprit préparé."
                      --Louis Pasteur

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

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



_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Kevin Kammer]

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.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

David Shaw wrote:
> 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.

When did this changeover take place, and is there any way to get the old
behavior back?



_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Kevin Kammer]

On Sun, Nov 08, 2009 at 09:46:08PM -0500 David Shaw wrote:

>
> 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
>

A perfectly phrased and logical explanation. Thank you for elucidating
this matter for me. What I failed to put together is that the size of q
must be defined at key generation time, and thereafter is an immutable
part of the key.

I imagine I may at some point have been using a key generated with an
older version of GnuPG, with a 224-bit q, and became accustomed to
the permissibility of SHA224.

Thanks again for your response,
Kevin

--
"Le hasard favorise l'esprit préparé."
                      --Louis Pasteur

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Kevin Kammer]

On Sun, Nov 08, 2009 at 10:17:52PM -0500 Robert J. Hansen wrote:
> David Shaw wrote:
> > 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.
>
> When did this changeover take place, and is there any way to get the old
> behavior back?
>

Unless there is some inescapable constraint on the size of one's
signature, I am hard pressed to think of a reason for using SHA224 when
SHA256 is available. However, the question is worth asking if only to
sate curiousity.

-Kevin


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

Kevin Kammer wrote:
> Unless there is some inescapable constraint on the size of one's
> signature, I am hard pressed to think of a reason for using SHA224 when
> SHA256 is available.

Conformance with corporate IT policies.  Many corporate IT policies are
drafted by people who don't really understand the underlying
technologies.  They see the NIST drafts and say "ah, 224-bit hashes are
to be used with DSA-2048," and proceed to require SHA224 to be used with
DSA-2048.



_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Kevin Kammer]

On Sun, Nov 08, 2009 at 11:11:01PM -0500
Also sprach Robert J. Hansen:

> Kevin Kammer wrote:
> > Unless there is some inescapable constraint on the size of one's
> > signature, I am hard pressed to think of a reason for using SHA224 when
> > SHA256 is available.
>
> Conformance with corporate IT policies.  Many corporate IT policies are
> drafted by people who don't really understand the underlying
> technologies.  They see the NIST drafts and say "ah, 224-bit hashes are
> to be used with DSA-2048," and proceed to require SHA224 to be used with
> DSA-2048.
>

Ah yes... corporate policy. How could I forget?

Having deployed PKI while I was in the military, I can certainly
sympathise with you regarding a large organization rigorously adhering
to policy, regardless of how much or little sense it makes.

The bright side is, the same documents which say SHA224 can be used with
DSA-2048 also permit SHA256. If anyone sets policy based on, say,
FIPS186, you can always cite that part.

-Kevin

--
"Le hasard favorise l'esprit préparé."
                      --Louis Pasteur

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[David Shaw]

On Nov 8, 2009, at 11:11 PM, Robert J. Hansen wrote:

> Kevin Kammer wrote:
>> Unless there is some inescapable constraint on the size of one's
>> signature, I am hard pressed to think of a reason for using SHA224  
>> when
>> SHA256 is available.
>
> Conformance with corporate IT policies.  Many corporate IT policies  
> are
> drafted by people who don't really understand the underlying
> technologies.  They see the NIST drafts and say "ah, 224-bit hashes  
> are
> to be used with DSA-2048," and proceed to require SHA224 to be used  
> with
> DSA-2048.

NIST, along with RFC-4880, says that you can use either 224-bit or 256-
bit hashes with DSA-2048.

David


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Werner Koch]

On Mon,  9 Nov 2009 04:17, rjh@... 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;



Salam-Shalom,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Kevin Kammer]

On Mon, Nov 09, 2009 at 11:52:48AM +0100 Also sprach Werner Koch:

> On Mon,  9 Nov 2009 04:17, rjh@... 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.

-Kevin

--
"Le hasard favorise l'esprit préparé."
                      --Louis Pasteur

_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[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@... 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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Robert J. Hansen-3]

David Shaw wrote:
> 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.

I agree with you about the need to make policy decisions, which is why I
wasn't asking for an option to be added or for the change to be
reverted.  Saying when the change was made and how to revert it is
enough for me -- if it becomes important to someone, the knowledge is
out there waiting for a Google search.

Thanks, Werner, for the code extract.  I appreciate it.  :)


_______________________________________________
Gnupg-users mailing list
Gnupg-users@...
http://lists.gnupg.org/mailman/listinfo/gnupg-users