Re: [openpgp] Followup on fingerprints

[Vincent Breitmoser <[e-mail]>]

> Maybe I missed an answer to this, but could someone please explain
> what the point of finding a collision on a pgp fingerprint is, and
> why we need to consider it as an attack scenario in the first plce?

I could have been more clear here: I saw the previous answer, but the
discussion went into the direction of collision feasibility without
really answering dkg's doubts about whether this was even a reasonable
scenario, and I'm not convinced it is.

> Mallet joins an open source project which only takes the first 100
> bits for the fingerprint. He uploads the key for M1 to a keyserver.
>
> He then commits a large number of malicious patches using M2 for
> authentication. These are all authenticated against his public key M2
> when he does the commit but the repository uses the key sent in band
> and does not keep the key for later verification.

So the premise here is:
- a user uploads his key, but it is not actually used other than for its
  fingerprint
- at authentication time, a public key sent by the user is used to check
  signatures, which is only checked to have the same fingerprint as the
  uploaded one
- the implementation uses truncated fingerprints for this

> At this point, any attempt to hold Mallet accountable is going to have
> to rely on a human examining the logs and working out that Mallet must
> have generated the malicious pair of keys. There is going to be no way
> to unwind the thing automatically.

And the actual attack is "slightly weaker non-repudiation"?

 - V