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@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
