Talk:Public key fingerprint

From Wikipedia, the free encyclopedia

[edit] Revamp?

I think the article currently not very useful – it shows an example of a fingerprint (random 160-bit number in hex), and then how one extracts the last 32 bits. Next it discusses the collision frequencies which is already covered by the birthday paradox article. As very short fingerprints, such as ones of 32 bits, are usually not assumed to be unique, I don't see how this is relevant. If nobody opposes, I would remove these. -- intgr 11:54, 19 November 2006 (UTC)

Rewrote the article and removed those in the process. -- intgr 23:04, 26 November 2006 (UTC)

Hence the power of Wiki. — Loadmaster 23:31, 18 December 2006 (UTC)

[edit] Couple of comments

1) Is it correct to say that 32-bit identifiers are "public key fingerprints"? PGP has short 32-bit identifiers, but it only calls them "Key IDs", and reserves the term "fingerprint" for the full-length identifiers. I believe I've only seen the term "fingerprint" used in this way, to refer to values which are a cryptographically-secure one-way-function of a public key.

2) The "Security of fingerprints" section seems wrong. The first sentences make the argument that an attacker who can "break" a hash function will only be able to find pre-images of a specific form, and the attacker will find it difficult to produce public-keys of specific forms for which he knows the private key.

However, neither of these seem good assumptions - without looking at a particular break, you can't a priori say what limitations the attacker will have on finding pre-images: he may be quite constrained, or he may not be.

Furthermore, public-key algorithms often provide attackers a fair degree of lattitude in choosing the bit-fields of public keys. For example, in RSA, an attacker who chooses a fixed N=p*q can calculate the private-key for any e. Diddling e could be used to exploit hash-function weaknesses, or to speed up brute-force preimage attacks.

Since it's best to be conservative in discussing security, I think this section could be made much shorter, simpler, and more correct by simply stating that, in general, the security of a fingerprint *does* rely on the preimage-resistance of the hash function.

Trevp 20:56, 18 December 2006 (UTC) —

Thanks for your review.

1) You're right, these truncated key IDs probably can't really be called "fingerprints". I've changed the section a bit and I hope it's more clear now.

2) As cryptographic hash functions are generally designed on the basis of confusion and diffusion, that is, it is extremely difficult to extract any kind of useful mathematic formula from them, I thought it was reasonable to assume that there could be no useful connection between knowing the public key fingerprint and being able to generate a keypair.

After a quick thought, though, I agree that the assumptions should probably be scrapped unless I can find a thorough paper to cite on the topic. Although PGP developers found MD5 fingerprints to be secure enough, and nobody is getting paranoid about these after weaknesses in MD5 have been pointed out (admittedly they are merely collision attacks at this point). -- intgr 08:03, 19 December 2006 (UTC)

Thanks for considering my comments! Let me think about this some more and see if I can formulate some text. Per your point that "I thought it was reasonable to assume that there could be no useful connection between knowing the public key fingerprint and being able to generate a keypair" - if the hash is preimage-resistant, then you're right that the best an attacker can do is brute force. But suppose the attacker can invert the hash function and find pre-images of a specific form (say, a chosen prefix, followed by a few blocks of random data, followed by a chosen suffix). Now the attacker just has to find a public key which matches that form. In this case, it's probably doable (see my example for RSA above). So that's an example of how a preimage break of the hash function could allow the generation of a keypair which breaks fingerprint security. Trevp 09:31, 20 December 2006 (UTC)

[edit] Proposed alternate text

(Intgr, I'm tempted to rewrite the article. Let me know what you think of below (still needs plenty of cleanup, references, etc.))

Go ahead and replace it, the minor issues can be worked out later. :) -- intgr 10:48, 21 December 2006 (UTC)

k, thx - done Trevp 11:58, 22 December 2006 (UTC)