Re: [openpgp] Followup on fingerprints

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Aug 3, 2015 at 10:42 PM, Vincent Breitmoser <[e-mail]>
wrote:

>
> > 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"?
>

The attack is to confuse someone's perl hack into letting someone get away
with something they should not.