Re: [openpgp] New fingerprint: which hash algo

ianG <iang@iang.org> Fri, 23 October 2015 20:43 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2571A907D for <openpgp@ietfa.amsl.com>; Fri, 23 Oct 2015 13:43:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 It1ojBeRGA5V for <openpgp@ietfa.amsl.com>; Fri, 23 Oct 2015 13:43:46 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3271A1A906F for <openpgp@ietf.org>; Fri, 23 Oct 2015 13:43:46 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id B8F046D753; Fri, 23 Oct 2015 16:43:44 -0400 (EDT)
To: openpgp@ietf.org
References: <878u84zy4r.fsf@vigenere.g10code.de> <55FD7CF0.8030200@iang.org> <87io742kz7.fsf@latte.josefsson.org> <87mvw4ctv5.fsf_-_@vigenere.g10code.de> <CA+cU71n1OUq4TtmY+8S2yfu2bvjAr+=DwtN-4xRW4xitjDpFXg@mail.gmail.com> <20151006110330.38b38ea4@latte.josefsson.org> <5616F2AE.5050106@iang.org> <561BAB91.8040104@epointsystem.org> <CAMm+LwjtzNzq-B78XwGoXFBRyJT4_6ZE0_-fojbw7=gbR9yvJw@mail.gmail.com> <87twph8ho5.fsf@alice.fifthhorseman.net>
From: ianG <iang@iang.org>
Message-ID: <562A9BFF.90708@iang.org>
Date: Fri, 23 Oct 2015 21:43:43 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <87twph8ho5.fsf@alice.fifthhorseman.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/KRo-KSQS9a4wh14Q14epl4GwsdU>
Subject: Re: [openpgp] New fingerprint: which hash algo
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Oct 2015 20:43:47 -0000

On 23/10/2015 21: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.


Yes, giving users "choice" in cryptographic algorithms is a bad idea in 
general.


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


IFF it is decided that there are two incompatible fingerprint schemes 
then they should be made unconfusable.

One way to do this is to use PHB's leading byte or nibble indicator.

Another way to do this would be to split the lengths such that one set 
of lengths is valid in one MD, and another is valid in another MD.  SO 
e.g., anything 8, 12, 16, 20 bytes long is SHA2 and 10,14,18,22 are 
reserved for SHA3, etc.

(Just for explanatory purposes.  PHB also has his 5-byte method which I 
quite like.)




iang



ps; just to re-iterate my view on multiple algorithms, I've yet to see a 
compelling argument, being one that is actually founded rather than 
circulated or based on claims of caution.