[openpgp] SHA1 collision detection in OpenPGP

[Daniel Kahn Gillmor <[e-mail]>]

Hey folks--

In the editor's copy of the crypto refresh of RFC 4880, there's a new
section about implementations can deal with SHA-1 when they encounter
it.  I wanted to send a heads-up to the WG about this text.

The end goal of course is for SHA-1 to be gone, but we need to recognize
that implementations will still be encountering data that uses SHA-1 for
quite some time, and outright rejection of all SHA-1 isn't always
possible.  For example, SEIPDv1+MDC still embeds the use of SHA-1 and
not everyone will be able to move immediately to SEIPDv2 and discard all
old encrypted material.

In particular, the upcoming draft gently suggests that when computing
SHA1 in any OpenPGP context, an implementation MAY consider adopting a
variant of SHA1 that is nearly identical, but detects known mechanisms
for creating SHA1 collisions, and creates either an error or changes the
output when they're detected.  This is known as "sha1 collision
detection":

https://openpgp-wg.gitlab.io/rfc4880bis/#name-sha-1-collision-detection

The full text currently is:

 15.1. SHA-1 Collision Detection

    As described in [SHAMBLES], the SHA-1 digest algorithm is not
    collision-resistant. However, an OpenPGP implementation cannot
    completely discard the SHA-1 algorithm, because it is required for
    implementing and reasoning about V4 public keys. In particular, the
    V4 fingerprint derivation uses SHA-1. So as long as an OpenPGP
    implementation supports V4 public keys, it will need to implement
    SHA-1 in at least some scenarios.

    To avoid the risk of uncertain breakage from a maliciously
    introduced SHA-1 collision, an OpenPGP implementation MAY attempt to
    detect when a hash input is likely from a known collision attack,
    and then either deliberately reject the hash input or modifying the
    hash output. This should convert an uncertain breakage (where it is
    unclear what the effect of a collision will be) to an explicit
    breakage, which is more desirable for a robust implementation.

    [STEVENS2013] describes a method for detecting indicators of
    well-known SHA-1 collision attacks. Some example C code implementing
    this technique can be found at [SHA1CD].


[ informative references ]

   [SHA1CD]
     Stevens, M. and D. Shumow, "sha1collisiondetection", 2017, <https://github.com/cr-marcstevens/sha1collisiondetection>. 
   [SHAMBLES]
    Leurent, G. and T. Peyrin, "Sha-1 is a shambles: First chosen-prefix collision on sha-1 and application to the PGP web of trust", 2020, <https://sha-mbles.github.io/>. 
   [STEVENS2013]
    Stevens, M., "Counter-cryptanalysis", June 2013, <https://eprint.iacr.org/2013/358>. 

If folks in the WG have objections to this, or concerns about it, it
would be good to hear!  (and, if you are ok with it, or think it's
wonderful, it would be good to hear that too -- we're not just looking
for negative responses)


    --dkg