Re: [openpgp] New fingerprint: which hash algo

Daniel Kahn Gillmor <> Fri, 23 October 2015 20:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 80F921A8A62 for <>; Fri, 23 Oct 2015 13:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LArliOFWcfJC for <>; Fri, 23 Oct 2015 13:16:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 87C8A1A8A55 for <>; Fri, 23 Oct 2015 13:16:42 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 0C0A7F984; Fri, 23 Oct 2015 16:16:38 -0400 (EDT)
Received: by (Postfix, from userid 1000) id C6FC71FF82; Fri, 23 Oct 2015 16:16:10 -0400 (EDT)
From: Daniel Kahn Gillmor <>
To: Phillip Hallam-Baker <>, "Daniel A. Nagy" <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
User-Agent: Notmuch/0.20.2 ( Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Fri, 23 Oct 2015 16:16:10 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: IETF OpenPGP <>
Subject: Re: [openpgp] New fingerprint: which hash algo
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Oct 2015 20:16:49 -0000

On Fri 2015-10-23 14:00:56 -0400, Phillip Hallam-Baker wrote:
> Due to the way OpenPGP works, it is not possible to have a recommended
> algorithm for fingerprints. Every client has to be able to process any
> recommended algorithm, so recommended means 'mandatory to accept'. But
> there should definitely be two algorithms to choose from.

In earlier discussions, i think people have made pretty convincing
arguments that "two algorithms to choose from" is not a useful
arrangement for OpenPGP fingerprints.

In particular, fingerprints are used in verification contexts where the
user has a bit of paper and sees something on the screen and is asked a
question "do these things match?"

If there are two algorithms to choose from, there are potentially two
fingerprints to choose from, and this process becomes more complicated.
the tool now has to either (a) first, ask the user which form of
fingerprint is on the bit of paper before displaying the fingerprint
(making fingerprint comparison a multi-roundtrip operation), or
(b) present both and hope the user knows to ignore one or the other
(similarly to how web browser certificate dialogs look, and we know how
well that works).

Either of these outcomes make this particular use case -- which already
has bad usability -- worse.

Arguably, we shouldn't encourage this use case at all, and should
replace it with something like "type in the expected fingerprint and
we'll tell you if it matches".  If we make that decision, the argument
for multiple fingerprint algorithms might be OK.  But while i use this
workflow myself, i think most users would find it too burdensome.
Reading high-entropy hexadecimal (or base64 or whatever) is bad enough.
typing it in is even worse.