On Dec 29, 2007, at 11:49 AM, Ralf S. Engelschall wrote:

> On Sat, Dec 29, 2007, Jeff Johnson wrote:
>
>>>> [...]
>>>> Do you really need key fingerprint checking?
>>>
>>> Yes, indeed. Sorry, but this is really essential and also the reason
>>> why I added fingerprint checking for gnupg() yesterday. One could
>>> "rpm --import" arbitrary pubkeys or even overwrite the pubkey on the
>>> filesystem, so it is actually *essential* to not just check whether
>>> a pubkey matched, but also to check the fingerprint of this signing
>>> pubkey to make sure something was signed by the *right* key.
>>
>> Whoa!
>>
>> The issue is whether a full 160 bits of SHA1 "key fingerprint" or  
>> just
>> the least significant 64 bits of "key id" need to be compared.
>>
>> Adding additional complexity to compare the full fingerprint to avoid
>> possible collisions in a 64bit space is what is being discussed, not
>> whether any random pubkey will do.
>> [...]
>
> Ah, sorry, now got it. Hmmm... well, in practice the last 64bit  
> might be
> ok, of course. OTOH I can imagine that people will argue that this too
> weak in the long-term. So, I would say, implement the 64-bit checking
> *now* and if it adds too much code complexity suspend the full 160-bit
> check for RPM 5.1. For me personally it is just important to be able
> to do fingerprint checking at all. If it is strong, very good. If
> it is weaker it is nevertheless still better than not checking the
> fingerprint at all.

Good. Paranoia is a disease, let's stay as healthy as possible. Even
160 bits won't be good enough some day. ;-)

I do point out that the fingerprint argument, and having rpm compare
the fingerprint to a "known good" value, whether the value is  
64/160/4096 bits,
solves no real world security problem.

The source of the pubkey data is either passed as binary/PEM encoded  
blob
(where rpm provides simple verification mechanics and its up to the  
caller), or
is retrieved from an rpmdb, which is "trusted" for other reasons,  
including being
root owned and a horrendously complicated complicated pathway to  
compromising
a system.

Adding an additional strcmp (which I will do) really changes very  
little, but
does provide a sanity check on the quality of application programming.

Back to hacking ...