Re: [openpgp] Deprecating SHA1

"Neal H. Walfield" <neal@walfield.org> Fri, 30 October 2020 12:25 UTC

Return-Path: <neal@walfield.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1D3A0E3B for <openpgp@ietfa.amsl.com>; Fri, 30 Oct 2020 05:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akhy-A_CC3uU for <openpgp@ietfa.amsl.com>; Fri, 30 Oct 2020 05:25:23 -0700 (PDT)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8973A0E39 for <openpgp@ietf.org>; Fri, 30 Oct 2020 05:25:22 -0700 (PDT)
Received: from pd9e79cc0.dip0.t-ipconnect.de ([217.231.156.192] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1kYTT5-0008SR-Nz; Fri, 30 Oct 2020 12:25:19 +0000
Received: from grit.huenfield.org ([192.168.20.9] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1kYTT5-00033t-6f; Fri, 30 Oct 2020 13:25:19 +0100
Date: Fri, 30 Oct 2020 13:25:19 +0100
Message-ID: <87a6w3x5n4.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>
In-Reply-To: <20201024165354.GD860779@camp.crustytoothpaste.net>
References: <87sga5xg03.wl-neal@walfield.org> <20201024165354.GD860779@camp.crustytoothpaste.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-2022-JP
X-SA-Exim-Connect-IP: 192.168.20.9
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NJpWerkG-V1AMxQ-wGHp1eOSwFc>
Subject: Re: [openpgp] Deprecating SHA1
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2020 12:25:25 -0000

On Sat, 24 Oct 2020 18:53:54 +0200,
brian m. carlson wrote:
> On 2020-10-23 at 12:51:08, Neal H. Walfield wrote:
> > So, two questions:
> > 
> >   - Does anyone see a safe way to accept SHA1 self-signatures today?
> >     Or (ouch!), if we want to be safe, do we have to convince ~10% of
> >     the sophisticated OpenPGP users to re-sign or regenerate their
> >     keys?
> 
> I think the time for transition with SHA-1 is gone.  The algorithm is
> estimated to be attackable for $45,000.  A thrifty and reasonably
> well-paid software engineer could put that away in a year or less.  It's
> within the budget of almost any medium or large business.

The attack presented in the paper is impressive, but it is perhaps not
as devastating as one might initially think.  In particular, it's not
a preimage attack, but a collision attack that relies on human help.
The attack is still dangerous, and I think we should deprecate SHA-1
in the near future, but there are a number of certificates out there
in active use (see my previous mails) that rely on SHA-1.  And, if
there is a safe way to continue to support them in the near term
(which I increasingly doubt is the case), I think we should.  And, we
should use the time that we buy to smooth the transition for users.

Currently, the ecosystem has radically different approaches to
handling SHA1.

In Sequoia, we decided to bad list SHA1.  (We still provide a
mechanism for a user of the library to say: I know that this artifact
has not been modified since T, so use a reasonable policy for this
authenticated time stamp.  For SHA1, we set the cuttoff to 2013.)

In reaction to the SHA-1 is a Shambles paper, Werner changed gpg to
disallow third-party certifications using SHA1 created prior to
19.1.2019 [1].  But, gpg still unconditionally permits self signatures
and binding signatures using SHA-1 (tested with 2.2.20 from Debian).

  [1] https://github.com/gpg/gnupg/commit/edc36f59fcfcb4b896a53530345d586f7e5df560

It's not clear to me that the impersonation attack presented in the
paper can't be adapted to self-signatures.  For instance, I think Bob
could get Alice to sign his key, then he could reuse that self
signature to add an encryption capable subkey to Alice's key using a
colliding binding signature.

Also gpg doesn't appear to authenticate the timestamp in third-party
certifications.  Although the attack in the paper hides the collision
blocks in the key material and user attribute, and assumes that the
signature packets are identical, it seems to me that it would be
possible with a bit more work to hide them in the signature packet's
hashed subpacket area.  Then, the attacker could control the signature
packets' creation times, and circumvent this defense, at least for
keys created prior to 2019.

My understanding is that the RNP developers don't bad list SHA-1 at
all.  In the future, they plan to add a special result code
RNP_SIGNATURE_WEAK, when a signature uses SHA1, but AIUI they still
plan to accept SHA-1 by default.  I'm not convinced that this will
cause users to be more careful.

  https://bugzilla.mozilla.org/show_bug.cgi?id=1641720#c3
  https://github.com/rnpgp/rnp/issues/1281

These different approaches make it harder to deprecate SHA1.  Even
though Sequoia tells a user that a certificate is unusable, because
the crypto it relies on is weak, if that user is like most users I
know, they will understand the message as: Sequoia can't do something
that these other implementations can do.  This places pressure on us
to find a way to safely accept at least the certificates that rely on
SHA1 and are in active use.

I think we could solve this problem if we as an ecosystem could find a
way to move forward together.  In this regard, the players in the
X.509 ecosystem are far ahead of us: they publish timelines to
deprecate algorithms, and most implementations seem to follow them.

> If we're provident, we'll specify some version of SHA-3 to be a SHOULD.
> Cryptanalysis is advancing on SHA-2.

I think this is reasonable.

> >   - What do people think about including a salt in the hash to make
> >     the content of the hash less predictable as described in [7]?
> 
> I know not everyone will agree, but I prefer deterministic signatures.
> There are use cases for OpenPGP with systems with little or no entropy
> using Ed25519 or deterministic ECDSA for signing.  Smart cards come to
> mind, for example.

I suggested adding the non-determinism to the hashed data (i.e., in
the signature packet), not to the data that is directly signed.  Most
smartcards that I know of are fed the hash.  So, in my proposal, it
would be up to the host system to generate the salt, not the
smartcard.

> Additionally, I don't think a salt is proof that a signature doesn't
> have a collision.  If the salt is generated by the attacker, then it can
> easily be part of the collision.  That could easily be the case if the
> signature came from a smart card or embedded device, where the salt
> might not be generated on the card.  We therefore cannot rely on it as
> evidence that a signature using a weak algorithm is secure.

I'm trying to save the self signatures.  So, the case that I'm worried
about is: Mallory convinces Alice to sign something, and the signature
can be repurposed to modify Alice's key, e.g., attaching an
encryption-capable subkey that Mallory controls to it.  A self
signature is over the primary key, a User ID, and a signature packet.
In this case Mallory doesn't control the primary key or the User ID.
So, he has to modify the signature packet.  Since he can't give Alice
a signature packet, he has to predict the signature packet's contents.
Today, modulo the time stamp, this is possible.  Adding a salt would
make this harder.  And, the authors of SHA-1 is a Shambles seem to
suggest that this would be a reasonable defense:

  Section 7.2 SHA-1 Usage in X.509 Certificates

  If some of the CAs still issuingSHA-1certificates use predictable
  serialnumbers, a similar attack might be possible today (being
  located at the beginning of the“to-be-signed” part of the
  certificate, if the serial number is unpredictable then the
  CPcollision attack is thwarted as a crucial part of the hashed input
  is not controlled by theattacker).

  https://eprint.iacr.org/2020/014.pdf

Thanks,

:) Neal