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

Daniel Kahn Gillmor <> Tue, 18 January 2011 02:51 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0I2p4iZ011232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jan 2011 19:51:04 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0I2p4bG011231; Mon, 17 Jan 2011 19:51:04 -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 p0I2p3ka011226 for <>; Mon, 17 Jan 2011 19:51:04 -0700 (MST) (envelope-from
Received: from [] ( []) by (Postfix) with ESMTPSA id 947A7F987 for <>; Mon, 17 Jan 2011 21:51:02 -0500 (EST)
Message-ID: <>
Date: Mon, 17 Jan 2011 21:50:57 -0500
From: Daniel Kahn Gillmor <>
Reply-To: IETF OpenPGP Working Group <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101213 Icedove/3.1.7
MIME-Version: 1.0
To: IETF OpenPGP Working Group <>
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-sha512"; protocol="application/pgp-signature"; boundary="------------enigF26F83C79B06F8C27FB9D0D0"
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

On 01/17/2011 09:14 PM, Jon Callas wrote:
> On the one hand, my only disagreement with you is to suggest that
> your proposal be tied into using SHA256 for a fingerprint.
> If you're going to expand the keyid to a fingerprint, why not
> get a better fingerprint?

hrm, interesting.

> On the other hand, this has never been a problem. It's harder than
> you think, because you have to generate a new key each
> time, which takes a while on RSA.

It's not as hard as all that, though, because an attacker trying to
force a collision of the low 64 bits doesn't need to care about two things:

 (a) the key creation time doesn't need to correct.  This gives them 32
bits to play with (or ~30 if they want to avoid timestamps in the
future) for brute force against a single generated RSA key.

 (b) for a non-cross-signed subkey, the RSA modulus itself doesn't need
to correspond to an actual secret key, since it doesn't need to make any
signatures.  So an attacker could flip arbitrary bits within the modulus
during a search for 64-bit collisions.

> Nonetheless, I think it's a good idea. I'd just go all the way to a better fingerprint.

That would sound reasonable if a consensus already existed on an
improved fingerprint, and if existing tools already used an internal
index with that fingerprint.  But the closest thing to consensus about a
new fingerprint that i've heard from this list is "wait for the outcome
of the SHA-3 NIST process", and i'd like to get something real-world
tools can produce before then.  (there seemed to be some disagreement on
this list about whether the material being digested for the fingerprint
would itself change, too).

So maybe: go with the "high 96" proposal for now, and when a consensus
forms for an alternate fingerprint format, introduce a new subpacket
type that uses that fingerprint.

Other thoughts?