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