My current GPG key was created in 2009 and very shortly afterwards I
changed the digest preferences as explained here:

http://www.debian-administration.org/users/dkg/weblog/48

and reuploaded the key to the keyservers with the new preferences, namely:

  Digest: SHA512, SHA384, SHA256, SHA224, SHA1

Now, if I create a test user in my system, generate a test GPG key
and try to download my key from the keyservers and sign it, I see that
it's still signed using SHA-1:

On the test user account:

gpg --export sanvila | gpg --list-packets

says:

:signature packet: algo 1, keyid 402E6FAD3BD8FC61 <=== key for the test user
        version 4, created 1381140424, md5len 0, sigclass 0x10
=====>  digest algo 2, begin of digest a0 67
        hashed subpkt 2 len 4 (sig created 2013-10-07)
        subpkt 16 len 8 (issuer key ID 402E6FAD3BD8FC61)
        data: [2045 bits]

I think there is something fundamentally wrong when keeping the
default gpg.conf untouched leads to signatures still made using SHA-1
and not even the preferences in the key are honored.

Note: I see that changing the preferences and reuploading the key is
implemented by adding another self-signature, in my case I see this:

gpg --list-packets pubring.gpg

:signature packet: algo 1, keyid MYKEYID
        [...]
        hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
        hashed subpkt 21 len 3 (pref-hash-algos: 2 8 3)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        [...]
:signature packet: algo 1, keyid MYKEYID
        [...]
        hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
        hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
        hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)

Could it be that gpg is completely ignoring the additional signature
having the preferences that I changed and it only sees the first one?

Am I supposed to revoke the first self-signature? I hope not. One would think
that if this preferences thing is implemented by using additional signatures,
then the fact that the new preferences have priority over the old ones should
be somewhat automatic.

BTW: I don't like to inflate severities, so I've used "normal" here,
but if I'm not missing anything and this is a real bug that should be fixed,
I think it would deserve an upload for stable.

Thanks.

If I understand properly what you're doing, this is not a bug.  The person issuing a signature is ultimately in charge to select the digest when they make the signature.  While you can set a digest preference on a key, it is merely a request for people making a signature for your benefit to use a digest that you like.  In GnuPG, the digest preference is consulted only for data signatures, not key signatures.

David

El 07/10/13 23:50, David Shaw escribió:

Well, it could be not a bug that gpg does not honor digest preferences
for keysigning. Maybe it should, or maybe there should be another set of
preferences for that.

But please note that the *real* problem I'm reporting is that key
signatures are made using SHA-1 by default.

I think this is a disaster. People should not have to modify gpg.conf to
get reasonable defaults. Is SHA-1 a reasonable default for key signing?

On Tue,  8 Oct 2013 02:05, sanvila@unex.es said:

It is the default becuase SHA1 one is a MUST algorithm for OpenPGP and
fingerprints are anyway compuyted using SHA1.  SHA256 is not supported
by all OpenPGP implementations.

BTW, what is your threat model?


Salam-Shalom,

   Werner

El 08/10/13 22:19, Werner Koch escribió:

Sorry but I'm not a cryptographer. Do you mean that as far as there is
not a known exploit, there is nothing to worry about?

There is a preference list for digests that I can set in my key and
publish on the keyservers, but apparently there is not a preference list
for the digest algorithm used in key signign (I naively thought the one
for digests was also valid for keysigning, I was wrong).

So, if I would like people to use stronger algorithms when signign my
key, what are my options? Tell everybody to modify their gpg.conf?
Or maybe the algorithm for signing is irrelevant and does not matter at all?

On Wed,  9 Oct 2013 01:09, sanvila@unex.es said:
"What do you want to protect against".  In this case you would for
example need to evaluate whether a collision attack on the hash is part
of the threat mode: Such an attack can only be mounted by the owner of
the signing key (the signing party) - but the owner could also create
two signatures on different files. So, this does not matter.

BTW, A second pre-image attack (finding data which yields the same hash
value as a specific given data) is way more complex than a collision
attack.  There are not even signs on how that can be done with SHA1.
Actually it is not even known how to do a collission attack on SHA1 -
but granted, we expect that this may happen in the next few years.

David already explained that.  The hash preferences work only in a
special case - usually there is no way for a verifying party to tell
the signing part what algorithm to use.  There is one signing party but
often hundreds or more of verifying parties.  Thus is is better to agree
on a widely deployed standard.


Shalom-Salam,

   Werner