Can someone explain the rationale for preferring to use one portion
of a fingerprint rather than another as a key id?
My interest is academic rather than strictly PGP related.
X.509 also uses key ids which are profiled to be fixed sized fields
containing a hash value, so the situation is not unique to PGP. My
assumption is that: 1) no particular bits of a good cryptographic hash
algorithm have any better collision resistance properties than any
other bits, and 2) there is no significant computation savings in
generating only a subset of the hash output, much less a difference in
generating only high bits vs. only low bits.
Is this assumption wrong, or are there other reasons that using the low
n bits of the output of a cryptographic hash as a key id is a blunder?
It would be unfortunate if the same mistake were repeated elsewhere.
Dave Kemp
(I considered the possiblity that the message from Hal was dated
1 April and was delayed in transit, and verified that it was not.)
Date: Thu, 25 May 2000 17:28:41 -0700
To: hal(_at_)finney(_dot_)org, ietf-openpgp(_at_)imc(_dot_)org
From: Jon Callas <jon(_at_)callas(_dot_)org>
Subject: Re: KeyID as left vs right substring of fingerprint
I agree that in retrospect, it would have been better to have the key id be
the high-order bits of the fingerprint rather than the low-order bits. I,
too, think this was a mistake. However, that decision was made before this
working group was formed. (And before I joined PGP, Inc. for that matter.)
I believe that changing this and making it be dependent on the algorithm
type would be utterly wrong. It would add one more little gnarly bit into a
system that is already filled with too many gnarly bits.
If this blunder needs to be fixed, the correct way to fix it is to make a
V5 key structure. (For that matter, there are a couple other things I'd
fix, too, if we made a V5 key structure.) However, I think that as
unfortunate as this is, simplicity and compatibility override aesthetics,
and we should just live with things as they are.
Jon
*****************************************************************************
This confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
******************************************************************************