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

Avi <> Thu, 20 January 2011 16:37 UTC

Received: from (localhost []) by (8.14.4/8.14.3) with ESMTP id p0KGb5no061176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jan 2011 09:37:05 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.14.4/8.13.5/Submit) id p0KGb5Yq061175; Thu, 20 Jan 2011 09:37:05 -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 p0KGb3MV061167 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <>; Thu, 20 Jan 2011 09:37:04 -0700 (MST) (envelope-from
Received: by ewy22 with SMTP id 22so358464ewy.16 for <>; Thu, 20 Jan 2011 08:37:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=1F+riRajksYNoIicw1B3yWlsUYawIBXUlPi+rKbjV7Q=; b=fhhj9zVEoxWok1Nx9OVxbI/4hYWIt60V9aMplQO9hcBIldS3Vnk0J+sC84w0NBTxub bPDQZGg/Ug45td35QdLi251CnGlxdDwsBVyp10TXSGTVF4siJJ5cnlLGzvUFDFHf54Z3 R/SQhXK+yK8yW4ntBoNVEv1xhpzY7gdhAxuHo=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=rX5HUNR3xYmJ10da1sgOft0lucGJQWXUKWKeTPjkHk3v8eDg8td/Jt1d7DPQMeXHTz V4VGJMW6KmR2wQ5FJCJxDgLhBCYpa1ahZkJim8Azt+BQmRGxZ64u3pI8a57XnwTh3GMm OXOAEmViSO9vzcQiwLCux8BRN/JtS4Soz8jQk=
Received: by with SMTP id p15mr3180932ebo.68.1295541422209; Thu, 20 Jan 2011 08:37:02 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 20 Jan 2011 08:36:32 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Avi <>
Date: Thu, 20 Jan 2011 11:36:32 -0500
Message-ID: <>
Subject: Re: including the entire fingerprint of the issuer in an OpenPGP certification
To: Jon Callas <>
Cc: IETF OpenPGP Working Group <>
Content-Type: multipart/alternative; boundary=0015174c3ffe433b5c049a49be94
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>

Hash: SHA512

Even more strongly, there is the difference between "almost
never" and "never". Even if there were an infinite number of key
id's along the real number continuum, the possibility of a
collision is mathematically 0%, but it is still possible. Heck,
the possibility of ANY id would be mathematically 0, but each
key would still have an ID.

Here, we are dealing with a discrete distribution, so there
/are/ mass points (be they VERY very small) at each ID, so yes,
it is 100% certain that eventually, not only will there be a
collision, but every key will have a collision. It may be
though, that the waiting time may be longer than the heat death
of the universe for the latter, so we don't have to worry about
that too much :).

- --Avi
Version: GnuPG v1.4.11 (MingW32) - GPGshell v3.77
Comment: Most recent key: Click show in box @



pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) <
   Primary key fingerprint: 167C 063F 7981 A1F6 71EC  ABAA 0D62 B019 F80E

On Thu, Jan 20, 2011 at 11:00 AM, Jon Callas <> wrote:

> Hash: SHA1
> A side-effect of this is something that's either an obvious extension or in
> the spec already.
> Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are
> unique."
> It's said that since 2440, for the following reason...
> In PGP1 days, Vinnie started working there and told me that he'd generated
> a key and gotten a certain error when putting it into the keyserver. I was
> thrilled, because that error was a duplicate keyid error. We'd been having
> debates over this ourselves. Being a software engineer, I tend to consider
> assuming that a database key is unique is bad form. I recognize that
> pseudo-random 64-bit numbers don't collide easily at all, but assuming
> uniqueness is something that is easily coded around. That key was my proof
> that engineering-wise, don't assume uniqueness.
> Sadly, he had deleted the key and just generated a new one, so that key is
> the Nessie of key ids. It's a crypto-cryptologist's dream, the true random
> collision. And we will never know if it was genuine. Sigh.
> Nonetheless, that led to that clause in 3.3, and I assert that if an
> implementation breaks because of a keyid collision, the implementation has a
> bug.
> So you can consider a keyid to just be a database key. The way we do it now
> (truncating a fingerprint) is a fine way to do it, but the underlying
> principle is that an implementor really needs to code around the eventuality
> that there will be a collision and do some right thing.
> Yeah, I know it's easier said than done, but that doesn't make it false.
> I forget what Terry Pratchett novel has it, but in one of them he has a
> discussion that anything that is a million-to-one against is a certainty.
> The million-to-one thing *will* happen. Cryptographers need to keep that
> principle in the back of their head, too.
>        Jon
> Version: PGP Universal 2.10.0 (Build 554)
> Charset: us-ascii
> Xs4TmguHftMh9uE/+b5Lqfw=
> =B98X