Re: [openpgp] New fingerprint: which hash algo

Phillip Hallam-Baker <> Mon, 26 October 2015 16:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ABCAC1B4574 for <>; Mon, 26 Oct 2015 09:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id heG_JcCijkUt for <>; Mon, 26 Oct 2015 09:02:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3684E1B2FF0 for <>; Mon, 26 Oct 2015 09:02:35 -0700 (PDT)
Received: by lffz202 with SMTP id z202so154660873lff.3 for <>; Mon, 26 Oct 2015 09:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xes95k7KlDl2358Z++ymPt6GNT/40bpAJ08UEdQ9nrE=; b=VhhKnc5WadRfElCmhHTdI+s4tAOlkiC+ugY6ttfmgohTWW2iNbVRD4EtW/bfDPr1f+ /iHRl58TM5sA/RRtbKp29US0KpsxoEQuMYxDqdLsDRyjnb1fXEO/c3oolTjzCWMIcKT+ Qh86pgjlb+ofFrMQ8zSyDirouVKF9s80S4tXnckwUnkTzpfqhEEH9aZCqSX8dFE7hYcN wSef/U/1tmVRDjzpjj0pwEc+N7935Odbtoqe430PPypKoXjRJPZbZPljnybHE2IC38bs 1hAZ2VrRC5ODjTcrUJ7TAMkALATEl4nMBwXfRfALMILpHqiVPBBEzlvz+OlS1XOCBa9R eraw==
MIME-Version: 1.0
X-Received: by with SMTP id zy2mr18312924lbb.79.1445875353454; Mon, 26 Oct 2015 09:02:33 -0700 (PDT)
Received: by with HTTP; Mon, 26 Oct 2015 09:02:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Mon, 26 Oct 2015 12:02:33 -0400
X-Google-Sender-Auth: 1zBS2L3vuvzoRqy9wJXZXigo1xo
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IETF OpenPGP <>, "Daniel A. Nagy" <>
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: Mon, 26 Oct 2015 16:02:36 -0000

On Fri, Oct 23, 2015 at 4:16 PM, Daniel Kahn Gillmor
<> wrote:
> 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.

As I pointed out, it isn't really a choice. Every client has to be
able to verify any fingerprint that can be generated.

> 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?"

Again, I did point out that issue. If you have more than one digest
algorithm, each has to result in a unique presentation. Hence the need
for tagging.

> 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).

Only if either you do it wrong or decide on one algorithm and pick the
wrong one.

That is the same problem that comes up with attacks involving
presenting a SSH key to OpenPGP or vice versa.

> 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.

I don't think that is right either. I would prefer to make comparison
a lot easier by going for visual comparisons. Base32 is a lowest
common denominator approach. I would like to have an alphabet of 2^16
words and 2^16 images as well.