Re: [openpgp] v5 in the crypto-refresh draft

Daniel Kahn Gillmor <> Sat, 05 June 2021 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C54E3A2ADF for <>; Sat, 5 Jun 2021 11:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=wicSmCSU; dkim=pass (2048-bit key) header.b=THADvA/c
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aqks-RkR13hK for <>; Sat, 5 Jun 2021 11:04:08 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA2093A2ADE for <>; Sat, 5 Jun 2021 11:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1622915702; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OA41EgKq50o4fxWJCzq2X0vhnZ2+tBe97fDpxwdWoQQ=; b=wicSmCSUGo5BrIspq8le3k95F+UWNV+5PBnH5pE5bcksHEjWdopimFCJo1S1y5Oejamd2 UTe0Wv/sdDslqfWDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1622915702; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=OA41EgKq50o4fxWJCzq2X0vhnZ2+tBe97fDpxwdWoQQ=; b=THADvA/cpOUtryanpj1QQhuX4Iwh+4nsQioFKSubz38/LwfcB4ulUvUy1xiTL14GMll4h l4I5/qsIdhkIDMvDc5AQvFggSVwIg9Av+jvWR5iq4Rp6UTH45yMGa/PQ8mB+urZPeAfILOk k2FuFwKksYeRkntjCNraZ/j7BN/zzxkyit0A4UGD+Y22PEVSvdOhqrNvRT5G3RuePhAdWmw ioCIa+dD33z4El1Bxfy0o3a+ftjmstGEx81duIXrTseI2c0cEzOPodTMrxtONmDgdx1bu1W Iub1b5aoZCA1neRzD/cPRG0qFTaW0f/gaXSqI61tHw60WDTP9JeAzxsLpAow==
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6A49DF9A9; Sat, 5 Jun 2021 13:54:59 -0400 (EDT)
Received: by (Postfix, from userid 1000) id C606220B32; Sat, 5 Jun 2021 13:54:56 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Peter Gutmann <>, Daniel Huigens <>
Cc: "" <>
In-Reply-To: <>
References: <> <> <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH
Date: Sat, 05 Jun 2021 13:54:54 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [openpgp] v5 in the crypto-refresh draft
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Jun 2021 18:04:14 -0000

On Sat 2021-06-05 11:20:48 +0000, Peter Gutmann wrote:
> The first thing to do when "fixing" SHA1 fingerprints, meaning breaking all
> existing fingerprints on the planet,

The draft as it stands doesn't "break all existing fingerprints on the
planet" -- it just says "when you're making a new OpenPGP key, make it
v5 and you and your peers won't have to think about SHA-1 any more when
using this key".  By using a v5 key an implementation would also be
effectively signalling its compatibilty with any updated MTI choices
(which we haven't gotten to yet, because we're still wallowing here).

This is a change that, granted, should have been made a decade ago so
that we could have some deployment by now.  But better late than never.

> is to define what properties they need to have.  I can't think of
> anything for which SHA-256 is OK but SHA-1 isn't, so before
> arbitrarily throwing SHA-256 in there we'd need to define what's
> needed for a fingerprint algorithm to see why -1 doesn't meet the
> requirements, and whether -256 does.

We've been over this ground before in the WG, and i don't think anyone
who thinks about it deeply will disagree with you re: collision

Nonetheless, fingerprints show up in many places, and many
implementations use them as unique identifiers, and can display
weird/broken behavior when encountering collisions, even if they're
sourced from the same (potentially malicious) actor.  Do we want to
encourage that kind of booby trap?  Furthermore, having to constantly
defend the use of SHA-1 when it is known to be deprecated *in other
contexts* is a tiresome exercise, and i think it'd be great if the
OpenPGP community could move past it.

We settled in the past iteration of this WG on SHA-256 as a
non-controverisal replacement, which is why it was re-merged into the
crypto-refresh draft.  If folks really want to re-litigate it, i suppose
that's possible, but i think we have bigger fish to fry (can we get to
those MTI changes, for example?) and I hope folks will think clearly
about whether such a detour is worthwhile.