Re: [openpgp] Followup on fingerprints

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2015-07-29 10:31:22 -0400, Phillip Hallam-Baker wrote:
> OK one thing from the meeting I forgot to mention, the security
> considerations have to address the use of a birthday attack by someone
> generating keys.

I'll echo Vincent here and ask what specific attack you're concerned
about.

My current understanding of OpenPGP fingerprints is that we do not need
collision resistance as a property of the fingerprint mechanism.

We've discussed the possibility of birthday attacks against fingerprints
by someone generating keys before, and i've yet to hear a concrete
description of any attack that this permits.  If there is such an
attack, then we need to be really concerned about it now, since the
current fingerprinting mechanism (SHA-1) is likely subject to a birthday
attack by a motivated and well-financed attacker.

> If we are doing ECC, it is quite practical for someone to generate 2^50
> keys and then pick the two that match in the first 100 bits. This can then
> be used for attacks, particularly if the keys are not enrolled in some sort
> of blockchain.

if we want to discuss append-only logs of key material, i'd be happy to
see that discussion happen formally in a separate thread, or over in the
certificate transparency WG where that sort of thing is already under
way.  I think dragging blockchains into a discussion on OpenPGP
fingerprint mechanisms is a distraction.

> The other bit I left out is the idea of compression. The idea here being
> that the person generating the key looks for a fingerprint that has 0s for
> the first n bits. Then the fingerprint starts with a version number that
> says 'the first 32 bits are 0s' or whatever.
 [...]
> My preference is to just truncate and use the inferred length. That allows
> us to minimize the amount of data we need to put in front of the user
> without compromising security.

These two proposals seem incompatible to me.  If you give me a
fingerprint that is shorter than the expected length, and both
mechanisms are available, how am i supposed to know whether you've given
me a truncated fingerprint or a "compressed" fingerprint?

> Lets say that in 2020 Alice meets Bob and they exchange their fingerprints
> via a 150 bit QR code. Alice's smartphone goes to the mesh and pulls the
> corresponding profile which has Bob's key and full 512 bit fingerprint. The
> phone then stores the big fingerprint for Bob in her contacts directory.

Wouldn't the phone just store the key itself instead of the fingerprint?
Why does the fingerprint matter in this scenario after the initial
introduction?

         --dkg