Re: [openpgp] Fingerprints and their collisions resistance

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 04 January 2013 04:27 UTC

Return-Path: <dkg@fifthhorseman.net>
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 6337921F8D44 for <openpgp@ietfa.amsl.com>; Thu, 3 Jan 2013 20:27:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 HbQXAhdXPH9K for <openpgp@ietfa.amsl.com>; Thu, 3 Jan 2013 20:27:26 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A142721F8D3F for <openpgp@ietf.org>; Thu, 3 Jan 2013 20:27:26 -0800 (PST)
Received: from [192.168.13.194] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id F2C4CF970; Thu, 3 Jan 2013 23:27:23 -0500 (EST)
Message-ID: <50E65A28.1070501@fifthhorseman.net>
Date: Thu, 03 Jan 2013 23:27:20 -0500
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0
MIME-Version: 1.0
To: Andrey Jivsov <openpgp@brainhub.org>
References: <50E530D6.6020609@brainhub.org> <50E5494E.6090905@iang.org> <50E60748.3040103@brainhub.org> <50E60F7A.8000001@fifthhorseman.net> <50E61BF7.4020905@brainhub.org>
In-Reply-To: <50E61BF7.4020905@brainhub.org>
X-Enigmail-Version: 1.5
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="----enig2RHSTXMNCJRNNBKMWDHDA"
Cc: openpgp@ietf.org
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: Fri, 04 Jan 2013 04:27:27 -0000

On 01/03/2013 07:01 PM, Andrey Jivsov wrote:

> Let's say I have a server that manages a domain of user, each have their
> own key, one at a time. Users can update their keys. They cannot remove
> keys (other than updating them). The server logs protocol actions and it
> uses key fingerprints to log changed to keys. The server decide to log
> the whole key on the key material change event, which it identifies by
> the change in the key fingerprint. Seems like a reasonable and secure
> system at first sight.

This sounds like a system that explicitly ignores the warning in RFC 4880:

>>    Note that there is a much
>>    smaller, but still non-zero, probability that two different keys have
>>    the same fingerprint.

https://tools.ietf.org/html/rfc4880#page-72

The purpose of a fingerprint is for one human to be able to securely
verify the key of another peer.  This means that they must be short
enough for humans to understand them, and they must resist preimage
attacks (no one should be able to come up with a new key that matches an
arbitrary fingerprint).

If your argument is "existing tools misuse fingerprints (and even
keyids) and treat them as unique identifiers when they should not" then
i'd have to agree with you.  We need to fix those tools.  If the
argument is "fingerprints need to be resistant to collision attacks, not
just preimage attacks because we want to be able to use them as unique
identifiers in cases like this that would allow for repudiation of
previously-signed messages where the earlier key was not properly
stored", then you're effectively doubling the length of the required
fingerprint for the sake of some problem better solved another way.  i
think that would defeat (or at least severely damage) the ability for
human beings to actually cognitively process the fingerprint.

It's arguably too difficult already for humans to accurately compare or
transcribe 160 bits of high-entropy data.  Asking them to compare or
transcribe larger fingerprints seems likely to result in operator error.

	--dkg