Re: [openpgp] Followup on fingerprints

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

On Thu 2015-07-30 10:44:48 -0400, Phillip Hallam-Baker wrote:
> 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.

Completely agreed that the security considerations should make a point
of calling out what we think are legitimate and illegitimate uses of a
fingerprint.

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

In either scenario, the committed code is done by Mallet, who was
explicitly authorized by the system to commit code.  So the failure here
is one of auditing, right?

And i think the implementation recommendation that would solve the
auditing problem here is "do not store fingerprints when you could be
storing keys" -- right?

Are there any other attacks we should be aware of due to failures of
collision resistance in the fingerprint?

> The connection is that each blockchain output can be used as an axiom of
> trust.

I don't know what an "axiom of trust" is, or why i would believe that
anything coming out of the blockchain would be one.  The properties i
think you're asking for are those of a global, append-only log.  whether
that's implemented by a blockchain or not seems like an implementation
detail.

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

Sure, so i think we're saying that fingerprints should be well-defined
enough to be entered into a global append-only log.  Do we need more
than that?

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

By "encryption" do you mean truncation or "leading-zero compression"?
it seems like we're starting to come up with multidimensional
representations of fingerprint formats.  I'm already uneasy with the
idea of having multiple forms of fingerprint -- if i'm given form M on
my peer's business card, and then i'm shown a key by my software that
uses form S (or form XS or form XM or whatever) how am i supposed to
compare them?

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

Following this logic, i think the answer is still that the endpoints
should store the keys that they think are currently valid and not the
fingerprints.  Fingerprints aren't for storage, they're either for
discovery or for verification.

          --dkg