How a digest algorithim is selected for a key signature

Key signatures, which are self-signatures to bind a subkey or user-id to a key or 3rd part certifications of a user id, are created by gpg with a digest algorithm selected this way:

1. If the option --cert-digest-algo is used, the given algorithm is used regardless on whether this makes sense or is possible by the underlying public key algorithms. A wrong specification may lead to all kind of errors. Thus this option should in almost all cases not be used.
2. If a DSA or ECDSA public key algorithj is used, the required digest algorithm is selected. For example a 1024 bit DSA key requires a SHA-1 signatures, a 2048 bit DSA key requires SHA-256. All ECC algorithms use a SHA-2 algorithm.
3. The default algorithm is used . in the default mode (explicit with option --gnupg or --compliance=gnupg) and with --compliance=de-vs the default digest algorithm is SHA-256. In the various OpenPGP compliance modes, SHA-1 is used due to the requirements out of the RFC.

The above is valid for the current stable GnUPG versions (>= 2.1). For GnuPG 1.4 the same algorithm is used but for compatibility with other OpenPGP implementations the default digest algorithm (for RSA) is still SHA-1.

• For 2.3 we should ignore all SHA-1 key certifications and warn about SHA-1 binding signatures and offer to migrate them.

• For 2.2 we may want to keep them as long as they carry an old timestamp (the current attack keeps the timestamp).

• RFC4880bis should even further deprecate SHA-1 use.

In my opinion, it's good if we can offer:

• a filter which can screen out possible fake keys
• a warning for key listing when detecting such keys
• The criteria for keys is:
  • with binding signature using SHA1
  • with non-standardish key length like 6144-bit
  • with JPEG user attribute (to be something like exactly 8192-bit)

, so that a user can make sure his keybox/keyring has no problem against attack.

Sorry, I have read the short paper wrongly. I misunderstood as if a forged key could be made using existing key.

It shows a possible attack to make a set of keys: key A and key B having same hash.

Thus, the impact is pretty small.

Perhaps, adding a warning message for an operation to certify a key with JPEG image using SHA-1 makes sense, so that signature for public key + JPEG image can't be abused for other public key + USER ID.

Attacks always get better and thus mitigation based on uncommon jpeg UATs would help only for a short time.
Maybe having a SHA-1 warning in 2.2 is also needed.