Re: [openpgp] Fingerprints and their collisions resistance

Andrey Jivsov <openpgp@brainhub.org> Sun, 06 January 2013 06:19 UTC

Return-Path: <openpgp@brainhub.org>
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 D1D5521F8804 for <openpgp@ietfa.amsl.com>; Sat, 5 Jan 2013 22:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzpFjYVx9a2r for <openpgp@ietfa.amsl.com>; Sat, 5 Jan 2013 22:19:31 -0800 (PST)
Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94A21F87FB for <openpgp@ietf.org>; Sat, 5 Jan 2013 22:19:31 -0800 (PST)
Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta12.emeryville.ca.mail.comcast.net with comcast id kW331k0010EPchoACWKWUm; Sun, 06 Jan 2013 06:19:30 +0000
Received: from [192.168.1.8] ([69.181.162.123]) by omta01.emeryville.ca.mail.comcast.net with comcast id kWKU1k00X2g33ZR8MWKVv9; Sun, 06 Jan 2013 06:19:30 +0000
Message-ID: <50E91770.3050203@brainhub.org>
Date: Sat, 05 Jan 2013 22:19:28 -0800
From: Andrey Jivsov <openpgp@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: openpgp@ietf.org
References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org> <50E88141.1030907@iang.org>
In-Reply-To: <50E88141.1030907@iang.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357453170; bh=J5Z9hy5CTkn9HLPdHAMwCjn0vrzOoNzHMftB3wNGk8A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k8QZ5D0O+CwjgXurnvA54Qg1V2FjcZiRcjQoY6nIZD5SPg+Uo7tcZnOPahYC+MZ3z yedtnT4u0XF+SANur9ApxdTVO1oxw9A6Jugih5ffBRX/Ml58JFn6/pMRqKGRHXWtPy gVwEDJyaqHFOxsZsL32zszNZphkiv/Ux7g4SZMXRvGVkaPxTv5jdqE2NV0IkgXPJPt lWsY1ZvqOO072pfQuuwlqMNY572E/BdoUop2a70AAwJFxHEyUNNcxAo0KggZ56D0pW 7gcQw0KLMzy4cZbd46aucx99l8cBvqXdgJXYEC0PWQk2S+oUCOomkyMwgD8HnmFOHG rixBBdaaBa7Mg==
Subject: Re: [openpgp] Fingerprints and their collisions resistance
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sun, 06 Jan 2013 06:19:32 -0000

On 01/05/2013 11:38 AM, ianG wrote:
...
> Although see 5.2.3.15 & 5.5.2 for interesting comments.  Let's ask for
> consensus on this point:
>
>    Are fingerprints cryptographically secure?
>
>    Or are they convenient human introduction handles?

I can live with the interpretation of RFC 4880 that implies that 
fingerprints are not cryptographically secure.

IMO, however, it would be beneficial if they were secure at the birthday 
boundary size.

I know that there were suggestions by multiple people to store complete 
keys. The problems are:
* keys are volatile; as a developer I want, at least internally in my 
software, a method to ID the key material; key material is often reused 
and traverses X.509 and OpenPGP world
* it's a convenience when the ID is of fixed size (think about database 
tables, software memory allocations, etc)

There is an objective need to ID the key material with a hash. I think 
at the very least we should spec the algorithm in an e-mail on this 
list. It would even be better if this algorithm was supported across 
applications, so that the IDs are portable.