Re: [Sks-devel] 32-bit (short ID) collisions: New milestone(?) reached

[Jeffrey Johnson]

> On Jun 4, 2016, at 4:44 PM, Kristian Fiskerstrand <address@hidden> wrote:
> 
> On 06/04/2016 12:43 AM, Gunnar Wolf wrote:
>> There are several tools relying on this (now very) weak 32-bit scheme;
>> the first such tool we found was precisely the «PGP pathfinder & key
>> statistics» service, which fails badly: Even specifying the full
>> fingerprints, I do get three (absolutely fake!) trust path into the
>> impostor:
> 
> I'd like to take a bit of time to comment on this. The web of trust in
> the abstract is all nice, but ultimately services such as the pathfinder
> is only a tool to guide in how you can find a direct path. It is not a
> replacement for actually properly configuring the trustdb and doing
> (local) signatures of external keys that are to be used in the validity
> calculation. So I fail to see an issue in this case, really, a simple
> tool can be fooled, but the underlying model is sound.
> 

I think that the effect of downloading a key with a collision in 32bits from an 
SKS
key server can be stated somewhat more simply/strongly (though I am sure
Kristian knows all this).

So a key, possibly the wrong key, possibly the wrong key(s) for an entire Wot
chain are downloaded from SKS key servers, all with collisions on 32bit keyid’s.

In order to verify, the issuer 8-octet keyid present in the signature packet is 
what
would typically be matched against the truncated digest of the key parameters: 
a mismatch
is identical to signature failure.

Comparing only 32bits of the issuer id in the signature, or assuming that the 
32bit
retrieval id applies to a pubkey without actually verifying the digest, are 
rather broken
implementation(s) imho. But even if the signature verify is attempted
with the wrong (because of a 32bit collision) pubkey, the signature is not going
to match: the signature algorithms will surely fail (and if not, there’s a much
more serious problem than 32bit keyid collisions resulting in the wrong pub key
being used).

This also applies to the signatures in the entire WoT chain, assuming that the
signature(s) are verified. It may not be obvious why the signature’s are not
verifying because of the 32bit collision confusion, but the verify result will 
almost
certainly be a failure.

If the key retrieval is flawed (because of widespread use of 32bit keyid’s), 
there is
little likelihood of a false verification when the retrieved pubkey is used. 
There is
the risk of confusion and the possibility of broken implementations that do not
verify retrieved information: but that needs to be corrected in implementations 
imho.

hth

73 de Jeff




> -- 
> ----------------------------
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> ----------------------------
> Public OpenPGP certificate at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> ----------------------------
> "We can only see a short distance ahead, but we can see plenty there
> that needs to be done."
> (Alan Turing)
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel