Re: [openpgp] Mining protection in fingerprint schemes

[Jon Callas <[e-mail]>]

> On Apr 8, 2016, at 7:49 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> On Fri 2016-04-08 15:32:32 -0300, Jon Callas <[e-mail]> wrote:
>>  One of the ideas we had a long time ago was that the "fingerprint"
>>  actually has two fields in it. A tag and a value. I'm still fond
>>  myself of the fingerprint that is
>> 
>>  <algorithm-id>:<algorithm-value>
>> 
>>  but I'm not wedded to the syntax. I like the idea; I don't care
>>  about the syntax.
> 
> The sense i got from the group was that we wanted one (and exactly one)
> fingerprint for any given key.
> 
> the proposal above means that i could compute a fingerprint for key X,
> and you could compute a fingerprint for key X, and then when we go to
> compare them they could be different (because one of us chose a
> different algorithm id than the other).  This makes fingerprint
> comparison a crapshoot, or requires one side of the comparisons to
> generate all possible fingerprints before they discover what the other
> side has done.

Noted.

I will mention that the advantage of a generic scheme is that it doesn't have to be revisited later when there's a new cool hash function that we all should use.

But the real reason for bringing that back was to give Bryan a hand. I see what he's wanting to do. He's wanting to create something that I will call the "authentication string." 

At present, we use the key fingerprint as the authentication string. The mining protection he's suggesting isn't a bad thing. My raised eyebrow comes from conflating the two. We need to have a "DB handle" and I believe the DB handle needs to be easy to compute (key-canonical is an orthogonal issue). The fingerprint gets used all over the place, especially in its truncated form as key-id.

So a way to get both is to make them not the same thing. Have it so that the thing that you print on your business card is the authentication string, and the thing that the software is using a lot is the db handle.

As it is, there are "fingerprints" used all over the place that aren't the user-visible one anyway, because the user-visible one is the fingerprint of the top-level signing key.

So stepping back even further, to have our cake and eat it two, we want to separate the two functions.

Anything that does that seems like a win, not just generalized fingerprints.

	Jon