Re: [openpgp] Fingerprint requirements for OpenPGP

KellerFuchs <KellerFuchs@hashbang.sh> Tue, 12 April 2016 17:23 UTC

Return-Path: <kellerfuchs@hashbang.sh>
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 052B812E0BE for <openpgp@ietfa.amsl.com>; Tue, 12 Apr 2016 10:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, SPF_PASS=-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 TVczRBoCBX3A for <openpgp@ietfa.amsl.com>; Tue, 12 Apr 2016 10:23:07 -0700 (PDT)
Received: from mail.hashbang.sh (mail.hashbang.sh [104.236.230.244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F397E12DFE3 for <openpgp@ietf.org>; Tue, 12 Apr 2016 10:23:06 -0700 (PDT)
Received: from to1.hashbang.sh (to1.hashbang.sh [104.245.37.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hashbang.sh (Postfix) with ESMTPS id 26E4C3CF7; Tue, 12 Apr 2016 17:23:06 +0000 (UTC)
Received: by to1.hashbang.sh (Postfix, from userid 3412) id 1A17CE00BA; Tue, 12 Apr 2016 17:22:46 +0000 (UTC)
Date: Tue, 12 Apr 2016 17:22:46 +0000
From: KellerFuchs <KellerFuchs@hashbang.sh>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Message-ID: <20160412172246.GE9034@hashbang.sh>
References: <87vb3nslqh.fsf@alice.fifthhorseman.net> <20160412083409.GA16775@littlepip.fritz.box> <87egaarj74.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87egaarj74.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/AZ6C1maSH8C1DB-eBteamPPL7vw>
Cc: IETF OpenPGP <openpgp@ietf.org>, Vincent Breitmoser <look@my.amazin.horse>
Subject: Re: [openpgp] Fingerprint requirements for OpenPGP
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 12 Apr 2016 17:23:09 -0000

On Tue, Apr 12, 2016 at 10:32:47AM -0400, Daniel Kahn Gillmor wrote:
> On Tue 2016-04-12 04:34:09 -0400, Vincent Breitmoser wrote:
> >Daniel Kahn Gillmor(dkg@fifthhorseman.net)@Mon, Apr 11, 2016 at 08:40:22PM -0400:
> >> * it should be strong enough that we do not believe anyone can create a
> >>   key with a fingerprint that collides with another key's fingerprint
> >
> > Quite importantly, this should be "another *independent* key's
> > fingerprint", i.e. the requirement is preimage resistance, not
> > collision resistance.  Creating two keys with colliding fingerprints
> > is fine, at least noone could come up with a attack scenario where it
> > mattered.
> 
> This clarification also matches my understanding.  Thanks for the
> precision, Vincent.

I think it is sane here to require collision resistence, because that's what
  multi-target preimages devolves to: an attacker might not want to target
  one specific key, but one amongst a large set of key (says, the developers
  of a popular software, or perhaps any “widely signed” key in the WoT).

In that case, the attacker gets a non-trivial speedup, and as the set of
  targets grows larger, the hardness of the problem devolves into that of
  finding a collision.

Moreover, colision resistence implies second-preimage resistence, and hash
  functions are usually considered “broken” by cryptographers once there is
  an attack for colisions, so it seems OK to be somewhat cautious here and
  require collisions to be hard.