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 (Gojō) 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
- [openpgp] Deprecating SHA1 Neal H. Walfield
- Re: [openpgp] Deprecating SHA1 Paul Wouters
- Re: [openpgp] Deprecating SHA1 Neal H. Walfield
- Re: [openpgp] Deprecating SHA1 Phil Pennock
- Re: [openpgp] Deprecating SHA1 Guillem Jover
- Re: [openpgp] Deprecating SHA1 Guillem Jover
- Re: [openpgp] Deprecating SHA1 Jonathan McDowell
- Re: [openpgp] Deprecating SHA1 Neal H. Walfield
- Re: [openpgp] Deprecating SHA1 brian m. carlson
- Re: [openpgp] Deprecating SHA1 Jon Callas
- Re: [openpgp] Deprecating SHA1 Phil Pennock
- Re: [openpgp] Deprecating SHA1 Phil Pennock
- Re: [openpgp] Deprecating SHA1 Peter Gutmann
- Re: [openpgp] Deprecating SHA1 Benjamin Kaduk
- Re: [openpgp] Deprecating SHA1 Ángel
- Re: [openpgp] Deprecating SHA1 Neal H. Walfield
- Re: [openpgp] Deprecating SHA1 Neal H. Walfield
- Re: [openpgp] Deprecating SHA1 Neal H. Walfield
- Re: [openpgp] Deprecating SHA1 Tobias Mueller
- Re: [openpgp] Deprecating SHA1 heikostamer
- Re: [openpgp] SHA1 Linter & Fixer Neal H. Walfield