Re: including the entire fingerprint of the issuer in an OpenPGP certification

"Daniel A. Nagy" <> Tue, 18 January 2011 10:01 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0IA18r7028576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 03:01:08 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0IA183l028575; Tue, 18 Jan 2011 03:01:08 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.4/8.14.3) with ESMTP id p0IA15OW028568 for <>; Tue, 18 Jan 2011 03:01:06 -0700 (MST) (envelope-from
Received: by bwz14 with SMTP id 14so3163955bwz.16 for <>; Tue, 18 Jan 2011 02:01:04 -0800 (PST)
Received: by with SMTP id e22mr3019021bkf.125.1295344864413; Tue, 18 Jan 2011 02:01:04 -0800 (PST)
Received: from [] ([]) by with ESMTPS id b6sm2522506bkb.22.2011. (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 02:01:03 -0800 (PST)
Message-ID: <>
Date: Tue, 18 Jan 2011 11:01:08 +0100
From: "Daniel A. Nagy" <>
Organization: ePoint Systems Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: IETF OpenPGP Working Group <>
CC: Daniel Kahn Gillmor <>, notmuch <>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig29B4C3D13C4C40618B3DA1EA"
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On 01/18/2011 02:47 AM, Daniel Kahn Gillmor wrote:
> i believe collisions of the low 64 bits of SHA1 are within reach today,
> i'd love to be corrected if this is not the case

I'd suggest using the entire fingerprint as a reference and leaving the
creation date out of the fingerprint calculation for v5 for the
following reasons:

Yes, generating two keys with identical long key ID's is feasible (and
not even particularly expensive on 64-bit machines with dozens of
gigabytes of RAM), but generating a new key with the same 64-bit key ID
as an existing key is on the very far end of the realm of feasibility.
Given the dubious gains from success, I would rule out this attack as

Another problem with fingerprints and key IDs is that they are generated
over the key and the creation date, meaning that the same key can have
different key ID's. Since the signature subpacket with the reference is
not part of the hashed data, one can change both the key ID and the
reference and keep the signature valid. Again, I don't know what the
practical value of such an attack might be, but just like in the first
case, it creates an odd situation potentially undermining the trust in
the security of the system. When arguing in front of a non-expert judge,
such quirks erode the claims of rock-solid evidence very badly.

The key ID itself (especially the long one) is not a bad idea, however.
It is a nice compromise in the middle of Zooko's triangle (almost
memorable, almost globally unique and almost secure). In order to make
it more useful, I'd suggest using 20-digit decimal identifiers (like
credit card numbers) instead of 16-digit hexadecimal ones.