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

["Daniel A. Nagy" <[e-mail]>]

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
impractical.

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.

Regards,

-- 
Daniel