ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Followup on fingerprints

2015-08-03 22:32:23
On Mon, Aug 3, 2015 at 10:42 PM, Vincent Breitmoser <look@my.amazin.horse>
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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp