Subject: Re: OpenPGP key fingerprints and stuff

From: Jon Callas <[email-masked]>
Date: Sat, 11 Sep 1999 17:25:54 -0700

At 4:12 PM -0400 8/30/99, John S. Bucy wrote:

>It would make my code substantially simpler if I could have a "signer's
>key fingerprint" instead.  And as the spec stands, I have to define my own
>subpacket type for it.  Since the ID can be directly derived from the
>fingerprint and they both have distinct, fixed lengths, it seems to me
>like you could unambiguously use either one or the other in the same
>subpacket without any other indication of which it was; if the length is 8
>bytes, its the ID, if its 20 bytes, its the fingerprint. Any thoughts?

You're perceptive, and in my opinion right. I agree with you 100%.

However, the reason the key ID is used is to be compatible with previous
implementations. PGP 2 used eight-byte key ids as a handle to look up the
proper key not only for signatures, but for encrypted data.

When we started OpenPGP, a number of us, myself included, wanted to take
the opportunity to clean up a number of things, like existence of key IDs.
I think that every place a key id is used, it should be a fingerprint
instead.

But. We have to be compatible with existing versions of PGP out there. So
we use key IDs, even though they have all the flaws you mentioned. That's
the only reason: we do it that way because that's the way we've always done
it.

	Jon

---

From: "John S. Bucy" <[email-masked]>
Date: Sun, 12 Sep 1999 13:54:29 -0400 (EDT)

> the only reason: we do it that way because that's the way we've always done

Someone else suggested that the problem of computing a key pair that has a
particular key ID is computationally infeasible.  I can't really speak to
this either way but it seems to me like 1: the probability of people
independentally randomly generating the same key pair (or keypairs with
identical fingerprints/keyIDs) is quite small and that 2: it would be
completely impractical for almost anyone (three-letter agencies excluded)
to try to exploit a system by systematically causing keyID collisions.

As far as my particular system goes, it seems like I have two options:

1.  Don't worry about key ID collisions.  Under most circumstances, I
think that this would probably be ok.

2.  Use a "signer's key fingerprint" signature subpacket and leave the
keyID packet there and ignore it.  Has the working group considered an
extension to OpenPGP to standardize such a thing (i.e. keyID Must
Implement, fingerprint Should implement)?  It seems like this would be
preferable to me defining my own subpacket type for my specific system...

later
john

(ps I'm not on the OpenPGP WG mailing list so please cc replies to me)

-------------------------------------------
John Bucy

"My mind is going....I can feeeeeeel it..."

[email-masked]
-------------------------------------------

---

From: Jon Callas <[email-masked]>
Date: Sun, 12 Sep 1999 19:33:52 -0700

>to try to exploit a system by systematically causing keyID collisions.

Yes, it's computationally infeasible to generate a key with a given keyID.
Or more to the point, if you can do it, you have found a flaw in SHA-1.
Publish it, you'll get kudos.

However, because the keyID is 64 bits long, when there are a total of 4
billion keys (0x1 0000 0000) in the universe, there is a 50% chance that
there is some collision of two keyIDs. These two people will be annoyed,
because all the present implementations assume keyIDs are unique.

>preferable to me defining my own subpacket type for my specific system...

In the long term, (2) is a good idea. But it's not just signatures that
need it. All places where a keyID is used really should move to
fingerprints. But it's not presently in the scope of this WG to fix all of
these.

If you make your own fingerprint subpacket, please use a notation subpacket
for it.

	Jon

---

From: [email-masked] (Lutz Donnerhacke)
Date: 13 Sep 1999 13:36:49 GMT

* John S. Bucy wrote:
>particular key ID is computationally infeasible.

This was never true. Source does exist since months. Natural collisions in
64bit are known to exist.

---

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 13 Sep 1999 10:27:21 -0500

In <v04210118b40211aa218f@[204.179.130.203]>, on 09/12/99 

>Yes, it's computationally infeasible to generate a key with a given
>keyID. Or more to the point, if you can do it, you have found a flaw in
>SHA-1. Publish it, you'll get kudos.

>because all the present implementations assume keyIDs are unique.

Actually, IIRC when I asked about keyID's long ago it was the consensus
that they were not unique and should be treated as such. I have been
coding under this assumption ever since.

>fingerprints. But it's not presently in the scope of this WG to fix all
>of these.

>If you make your own fingerprint subpacket, please use a notation
>subpacket for it.

IMHO I just don't see a need for it anytime in the near future. While
there is the chance for collisions (I think it is greater than your
estimate above) it is quite remote on the client end. It seems to me that
this is mostly a server issue though the client software shouldn't choke
on it.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.openpgp.net
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
Talk About PGP on IRC EFNet Channel: #pgp Nick: whgiii

Hi Jeff!! :)
---------------------------------------------------------------