SHA-1 deprecation timeline

Werner Koch wk at
Fri May 13 11:21:00 CEST 2016

On Fri, 13 May 2016 07:04, rjh at said:

> As far as the OpenPGP use case, SHA-1 is not yet broken.

In fact, all not too old keys have been created with preferences for
SHA-256 and that is what all modern installations are using.

The use of SHA-1 in OpenPGP is pretty limited and we are well aware of
future threat models for theses usages.  The primary use for SHA-1,
which is hardwired to a key, is to compute a fingerprint.  To use this
for an attack, you do not need a collision but a second preimage -
entirely out of scope for SHA-1 for now and I am pretty sure that the v5
key format will be in wide use by the time well funded organizations can
create such a second preimage for a SHA-1 fingerprint.  Anyway, it is
ridiculous to assume that the TLAs will spend a huge amount of money for
this because there are too many really cheap ways to get the same
result; it is all about the money.  To quote Brian Snow of the NSA: We
don't break algorithms - we cheat.

As always in security one needs to evaluate the threat model before it
is possible to describe a risk level.

The goal in the world of free cryptography is thus too increase the
costs for an attacker so to make mass surveillance impossible.  For
targeted attacks we need to care about _security_; this is a immense
larger domain than the simple algorithm things.

Anyway, we will keep up to modern standards but not at the costs of
alienating most users.

> that SHA-1 needs to be supported for at least the next decade just to
> interoperate with legacy systems and traffic.

Yep.  And there are still proper use cases for SHA-1 outside of

> Deprecating an optional algorithm (like MD5) is pretty easy.  Removing a

In reality not that easy, if you take the flak we got for dropping PGP-2
support (which is based on MD5) in account.

> You've already been told what has to happen.  Once the IETF OpenPGP
> Working Group publishes a new RFC with guidance for what should be done
> about SHA-1, GnuPG will implement that RFC in short order -- my guess is

Those folks (paranoids or really heavily targeted) behind an air-gaped
i386 box, running whatever tiny OS and C compiler they have audited, and
still trust the complexity of GnuPG, should put

  weak-digest SHA-1

into their gpg.conf to reject SHA-1 based signatures.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
    /* EFH in Erkrath: */

More information about the Gnupg-devel mailing list