Re: [openpgp] Summary v5 fingerprint proposal

Vincent Breitmoser <look@my.amazin.horse> Thu, 23 March 2017 19:58 UTC

Return-Path: <look@my.amazin.horse>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3413165A for <openpgp@ietfa.amsl.com>; Thu, 23 Mar 2017 12:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 RDtzledqBkxL for <openpgp@ietfa.amsl.com>; Thu, 23 Mar 2017 12:58:24 -0700 (PDT)
Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3FB129BB0 for <openpgp@ietf.org>; Thu, 23 Mar 2017 12:58:23 -0700 (PDT)
Received: from localhost (p5481CA54.dip0.t-ipconnect.de [84.129.202.84]) by mail.mugenguild.com (Postfix) with ESMTPSA id 5B0215FA71; Thu, 23 Mar 2017 20:58:21 +0100 (CET)
Date: Thu, 23 Mar 2017 20:58:18 +0100
From: Vincent Breitmoser <look@my.amazin.horse>
To: Jon Callas <joncallas@icloud.com>
Cc: Werner Koch <wk@gnupg.org>, "openpgp@ietf.org" <openpgp@ietf.org>, "HANSEN, TONY L" <tony@att.com>
Message-ID: <20170323195818.l3trinds446zjsj2@calamity>
References: <8737e4o2e4.fsf@wheatstone.g10code.de> <CAAu18hcEGGaDjKXtXpPbzxKm-8T4PWQBFq6AmbRXLUwi_z=0XQ@mail.gmail.com> <728801D2-CB96-4584-8A79-C93278B0437F@att.com> <87poh8kkfi.fsf@wheatstone.g10code.de> <35F1365E-C728-4925-BFB0-F31A3D8EC8FF@icloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <35F1365E-C728-4925-BFB0-F31A3D8EC8FF@icloud.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/46omB-rrgs0f7NbxUQLQrSzFUQo>
Subject: Re: [openpgp] Summary v5 fingerprint proposal
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 23 Mar 2017 19:58:27 -0000

Jon Callas(joncallas@icloud.com)@Thu, Mar 23, 2017 at 11:55:00AM -0700:
> The real reason to use a wider hash is that every time we've
> compromised on security for the sake of small devices, it bites us in
> the ass. This will also bite us in the ass. It's a small bite in the
> grand scheme of things, but it's going to happen and it will be
> inconvenient.

Is your point that we should use *more* than 256 bits for an identifier
that doesn't even need preimage resistance?

There are four use cases for such an identifier:

 - provide a reference to a key in signatures. note that this is not a
   cryptograhpic purpose, since the actual signatures are calculated
   over the entire key. we have been using 64 bit key ids for this
   purpose so far.

 - show to humans to have them verify two keys are identical. by
   definition, we trust the person showing this fingerprint, which
   renders collision a pointless attack scenario.

 - use as a handle for a designated revoker. assuming there is a
   collision, either colliding key could be used for revocation. since
   those would both be generated by an attacker in either case, there's
   no issue.

 - use as a handle for obtaining (downloading / updating) a key. a
   keyserver (or equivalent) could equivocate here, but *only* if they
   control the looked-up fingerprint in the first place, or at least
   generated the (colliding) key.

Am I missing a use case? Even including a ton of security margin, 256
bits already seems way overkill to me for any of those purposes.

 - V