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

Daniel Kahn Gillmor <> Wed, 09 June 2021 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBA9C3A28BA for <>; Wed, 9 Jun 2021 15:29:01 -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=RT8og1Lh; dkim=pass (2048-bit key) header.b=UFObsZSL
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2jf9YigADzVZ for <>; Wed, 9 Jun 2021 15:28:55 -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 D56493A28B8 for <>; Wed, 9 Jun 2021 15:28:54 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple;;; q=dns/txt; s=2019; t=1623277732; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=PC5v5nPG7sC0mi9HRIHdVbgXXAdwZG1nf0dE3oEyePc=; b=RT8og1LhJIizA9uy3BRnP9ESaFOQbHq48/0uzJvKLxTWVmbLow3qCk5GIhYlWu8AsLwWz C4JTOmPuclypkEZAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; q=dns/txt; s=2019rsa; t=1623277732; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=PC5v5nPG7sC0mi9HRIHdVbgXXAdwZG1nf0dE3oEyePc=; b=UFObsZSLrKPIKdYNQJSb9IyYlQwhvn0aJp80eU09CvP84/I2DRcWg+lSF7BT5NAQOXtbh oPrOgukwdfyu+QlvpCxUBFEyoBlh6RvUWKGGzdbFChlpTvHLrhpinnga7aG6bgzbOb1+n5o nGIqIMCL4Tn9KEt9izh5c6LAQ9nuyUBudMhGWb1HFDnV16j6IklAMSPRRsC+Rljr+8uWnPK Ps4JUsFlyPlgZFHgLDGTWqtWd2eJDTSWPPHE7d/OHutaC6IvAq1CoT9I1iX4tBIkJlX/kcu RsvSa1vLVWvDe8/Ywtr25PnptqOCQBQYDlBZbdiw+vA6CTun9uFYUPrEuL9g==
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 4A518F9A6; Wed, 9 Jun 2021 18:28:51 -0400 (EDT)
Received: by (Postfix, from userid 1000) id D9F802030E; Wed, 9 Jun 2021 15:09:47 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Paul Wouters <>, Peter Gutmann <>
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: Wed, 09 Jun 2021 15:09:46 -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: Wed, 09 Jun 2021 22:29:02 -0000

Thanks for raising this concern, and for proposing text, Peter.

While the standard itself actually uses fingerprints and keys rarely
(only in the "issuer", "issuer fingerprint" and "revocation key"
subpackets), I think for this discussion we should remember the most
sensitive context for use of key IDs and fingerprints, which i'll call
the "comparison-verification" practice:

Key ID or fingerprint comparison has been recommended in the past by the
OpenPGP community as a reasonable way that one communications peer can
confirm that they have the "right key".

I grant that comparison-verification is not specified in RFC 4880, but
we can't pretend it doesn't happen either.  (the fact that people are
not actually very good at performing comparison-verification is itself a
separate issue)

Peter Gutmann wrote:

>> There are no cryptographic issues introduced by this

I'm concerned about the unclear antecedent to "this" here.

It might be read as saying that there are no cryptographic issues
introduced by 64-bit key ID collisions, but i think it's talking only
about 160-bit fingerprint collisions.

There may well be cryptographic risks for any user or implementation
that uses comparison-verification based on key IDs specifically -- it's
downright cheap for a third party to generate a colliding 32-bit key ID
(cf evil-32), and within plausibility for a third party to generate a
colliding 64-bit key ID, even assuming a theoretically perfect hash
function (particularly if any one of a pool of potential keys can be
targeted: the larger the pool, the faster the brute-force attack).

>> since the fingerprint is merely a fixed-length opaque value used to
>> identify the variable-length structured data that makes up a public
>> key.

I don't think this sentence characterizes the entire argument.  If the
fingerprint were calculated over any *externally-supplied* data in
addition to the data generated by the keyholder, it *would* be a
cryptographic issue, because the provider of that external data might be
able to manipulate the fingerprint, which could then be used to break
any comparison-verification practice that uses full fingerprints.

The fact that the fingerprint is calculated over data that is intended
to be supplied uniquely by the keyholder is what makes SHA-1's weak
collision-resistance a non-issue in this context.

>> In particular the move to SHA-256 for V5 fingerprints was made not to
>> address any cryptographic vulnerability but to avoid the perception
>> that something insecure might be happening due to the use of SHA-1.

On Mon 2021-06-07 14:45:53 -0400, Paul Wouters wrote:
> With no hats on, I would probably change the latter bit to:
>    In particular the move to SHA-256 for V5 fingerprints was not made to address
>    any cryptographic vulnerability, but was made to follow the generic
>    guidelines of the cryptograhic community to sunset the use of SHA-1.

I'm fine with either of these two framings, with a slight preference for
Paul's text as it captures a bit more of the shifting landscape.