Re: including the entire fingerprint of the issuer in an OpenPGP certification

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

On 01/17/2011 09:14 PM, Jon Callas wrote:
> On the one hand, my only disagreement with you is to suggest that
> your proposal be tied into using SHA256 for a fingerprint.
> If you're going to expand the keyid to a fingerprint, why not
> get a better fingerprint?

hrm, interesting.

> On the other hand, this has never been a problem. It's harder than
> you think, because you have to generate a new key each
> time, which takes a while on RSA.

It's not as hard as all that, though, because an attacker trying to
force a collision of the low 64 bits doesn't need to care about two things:

 (a) the key creation time doesn't need to correct.  This gives them 32
bits to play with (or ~30 if they want to avoid timestamps in the
future) for brute force against a single generated RSA key.

 (b) for a non-cross-signed subkey, the RSA modulus itself doesn't need
to correspond to an actual secret key, since it doesn't need to make any
signatures.  So an attacker could flip arbitrary bits within the modulus
during a search for 64-bit collisions.

> Nonetheless, I think it's a good idea. I'd just go all the way to a better fingerprint.

That would sound reasonable if a consensus already existed on an
improved fingerprint, and if existing tools already used an internal
index with that fingerprint.  But the closest thing to consensus about a
new fingerprint that i've heard from this list is "wait for the outcome
of the SHA-3 NIST process", and i'd like to get something real-world
tools can produce before then.  (there seemed to be some disagreement on
this list about whether the material being digested for the fingerprint
would itself change, too).

So maybe: go with the "high 96" proposal for now, and when a consensus
forms for an alternate fingerprint format, introduce a new subpacket
type that uses that fingerprint.

Other thoughts?

	--dkg