At 1:54 PM -0400 9/12/99, John S. Bucy wrote:
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.
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.
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...
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
If you make your own fingerprint subpacket, please use a notation subpacket