Re: [openpgp] Should fingerprints be "key-canonical"?

[Jon Callas <[e-mail]>]

> On Apr 8, 2016, at 8:15 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> On Thu 2016-04-07 20:33:56 -0300, Jon Callas <[e-mail]> wrote:
>>  Yes, because I can tell you that it's *really* useful to be able to
>>  reuse the key material from [e-mail] for (e.g.)
>>  [e-mail] or security, or whatever. I've done it a lot over
>>  the years.
> 
> What is the utility here, specifically?
> 
> I appreciate making tracking/linkability harder as a goal, but i'm not
> conivnced that this achieves that purpose.

Let me rewind then. PGP 2 had key-canonical fingerprints. There were issues with them. Nothing particularly horrible, but they we all of the sort of fun and games that you can play with the emergent properties of hash functions. And really, I can't remember them all that well because that was ages ago.

PGP 3 and thus OpenPGP threw the creation time in there as a quickie salt. I didn't do it. I don't know the full reasons. 

I originally thought this was dumb. I got turned around, and believe that salting the hash is a good thing. I know that I have used this property so that I can re-use key material, but it's not the total reason.

I can think of a bunch of half-assed things someone can do with key-canonical fingerprints if they are, say, the NSA. Nothing that's an attack, but just stuff.

If anything, I think that salting the hash ought to be with more than the timestamp. But really, I'd keep the fingerprint computation the same, just with a more modern algorithm than SHA-1. The problem we're trying to solve is that SHA-1 is old. I like to change only one knob at a time.

Most of all, I think that semantic properties like this shouldn't change without a reason. At present, there are uses, questionable as they are, for this, and why break it just because?

Right now, we know that for every fingerprint there is a key (modulo hash collisions), but a key can have many fingerprints. Why to we want to change it so that there's one-to-one correspondence between keys and fingerprints? This sounds to me like it's vaguely surveillance-friendly.


> 
> Anyone who has the keys for [e-mail] and [e-mail] can
> tell that these are the same keys, and can just join them in their
> linkability/trackability database.
> 
> Furthermore, it introduces additional management problems for Alice; if
> she loses control of the secret key material, she now has to ensure that
> she's generated a revocation certificate for each "flavor" of it,
> because the revocations are bound to the same material that the
> fingerprint is bound to.

So? The reason to break the binding between key material and a certificate is so that there's no binding.

Actually -- this sounds like as much a reason to salt it. There are more reasons to revoke than loss of key material, and this means that revocation is even less useful.

	Jon