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