Page MenuHome GnuPG

OpenPGP Key Certification Forgeries
Closed, ResolvedPublic


Tracking INRIA report about applying a new chosen-prefix collision attack on SHA-1 on OpenPGP SHA-1 binding signatures. The report is a 4 page paper by Gaetan Leurent and Thomas Peyrin.

Related Objects

Event Timeline

werner created this object in space Restricted Space.
werner created this object with visibility "Subscribers".

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.

Mitigations are in place for quite some time now; see T4755.

werner changed the visibility from "Subscribers" to "Public (No Login Required)".Aug 13 2020, 11:44 AM
werner shifted this object from the Restricted Space space to the S1 Public space.