Re: [openpgp] Followup on fingerprints

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

On Thu, Jul 30, 2015 at 12:04 AM, Daniel Kahn Gillmor <[e-mail]
> wrote:

> 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.
>

That depends on the use cases you anticipate for OpenPGP and what you
expect people will build on top.

The thing is that OpenPGP is not just an email security application, it is
infrastructure. A lot of stuff is built on top of the spec that has nothing
to do with email.

That does not mean we have to support those applications. But it does mean
that we have to write a security consideration telling people we have (1)
considered the issue and that (2) either it isn't a problem or you should
do stuff that is going to be affected.


The concern here is that Mallet generates two keys that have the
fingerprints

Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and .
Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2'

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.

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.


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 connection is that each blockchain output can be used as an axiom of
trust. Since the purpose of fingerprints is to represent roots of trust,
this is a possible use case that the spec should be capable of
accommodating without opening up the question of how precisely that would
be achieved.




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


Well, the fingerprint version tag would have to flag that encryption is
being used. So instead of the fingerprint being Mxxxx-.... (SHA2-512) or
Sxxxx-... (SHA3-512), it might be Xxxxx-...


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

OK, 'at least the 512 bit fingerprint'...

Which you do probably depends on if you are using ECC or RSA. With RSA,
those 2048 bit keys start to bulk up...

For my particular implementation, I want to be able to rotate encryption
keys on a monthly basis or any time a device is added or removed from a
user's profile. so I am using fingerprints of key signing keys rather than
end-entity keys.

As a general rule, it seems that you can solve pretty much any usability
problem at the cost of an additional key. Back in 1995, this would have
ground the whole net to a halt. Today it isn't a problem. Right now on my
testbed Alice has a personal profile of 3 keys, plus a device profile of 3
keys per device, plus individual keys for each use in application (1+1 per
device for email, 1 for 2 factor auth, 1 for admin, 1 for data encryption,
1 for drive encryption). So assuming Alice has 2 desktops, a laptop, a
tablet, a phone and a watch, that is 3 + 18 + 7 + 6 = 30 keypairs and an
additional one per month.

It might sound a bit extreme, but since I started in the business, machines
have gotten roughly a million times faster and have a million times the
memory. 30 keypairs instead of one does not seem like a big deal.