3

Should the fingerprint of a renewed (extended) OpenPGP Key be the same? Is there any documentation on it (RFC)?

Quoting from RFC 4880:

There are many ways possible for two keys to have the same key material, but different fingerprints (and thus Key IDs).

Specially the bold part, so I guess that changing the fingerprint would also result in changing the key ID hence make the key useless, correct?

6

OpenPGP Key IDs

OpenPGP key IDs (and fingerprints) are used to reference keys when performing several actions like requesting and sending keys, or when verifying ownership. For example, you'd exchange the fingerprint with the key's owner on a separate, trusted channel to make sure the key really belongs to the person that claims to own the key.

The OpenPGP (v4) key ID is an identifier calculated from the public key and key creation timestamp. From those, a hashsum is calculated. The hex-encoded version is called the fingerprint of the key. The last (lower order) 16 characters are called the long key ID, if you only take the last eight characters, it's the short key ID. An example for my own public key:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

The primary public key's ID is referenced in the pub line after the key size, in your case the short key ID is CB3AF6E6:

pub   4096R/CB3AF6E6 2015-12-24 [expires: 2016-12-23]

Be aware the eight byte short key IDs do not provide a sufficiently large value space, and it is easily possible to generate duplicate keys through collision attacks. Instead of short key IDs, use at least long key IDs, and when software handles keys, always refer the whole fingerprint.

For more details on how the hash sums are derived, I refer to RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints which also explains the differences for deprecated OpenPGP v3 keys.

Different Fingerprints/Key IDs for the Same Key Material

The RFC you're quoting refers to "many ways" to have the same "key material" have different fingerprints (and thus key IDs). First of all, one should discuss what "key material" includes; I'd suggest that the author was referring to the numbers forming the key only, not meta information like the key creation timestamp. Also, I'd not really consider the number of ways to get different fingerprints for the same key material as "many". I can only see two ways (without claiming the list to be complete, at least I should not have missed something obvious):

  • As already discussed above, v3 and v4 OpenPGP keys have different fingerprint calculation methods, so the same key pair will result in different fingerprints. This is also noted in the RFC:

    Perhaps the most interesting is an RSA key that has been "upgraded" to V4 format, but since a V4 fingerprint is constructed by hashing the key creation time along with other things, two V4 keys created at different times, yet with the same key material will have different fingerprints.

  • Different key creation timestamps will result in different fingerprints. This is what was used by the Evil32 key collision attack to create lots of seemingly different fingerprints using few keys (key generation is expensive, while just iterating timestamps and calculating hash sums is cheap).

Will my OpenPGP fingerprint ever change?

Should the fingerprint of a renewed (extended) OpenPGP Key be the same? Is there any documentation on it (RFC)?

[...] I guess that changing the fingerprint would also result in changing the key ID hence make the key useless, correct?

If you extend the validity period, the fingerprint will not change at all -- you're neither changing the numbers forming the "key material", nor are you changing the key creation timestamp.

By extending the validity period, a special self-signature storing the expiry date will be issued. This signature has its own timestamp included, and will override any former expiry dates, so that any other user of OpenPGP will have the new expiry date merged into your old key.

Yes, if the fingerprint changes, your key would be rendered useless (in the sense that it seems to be another key), as the fingerprint is used as reference for both certifications and other usages of keys. But that's merely theoretical, as fingerprints won't change in practice.

  • "a special self-signature storing the expiry date will be issued" Is this automatic or manual process? Is this part of v4 or earlier versions also support this? – Kirill Sinitski Oct 31 '16 at 17:06
  • This is the only operation performed when a key/certificate is extended. You have share the key with the updated self-signature, of course. This applies to both v3 and v4 keys. – Jens Erat Oct 31 '16 at 17:10
2

Fingerprint is a hash of a public key, if your public key changes then your fingerprint would change as well. Now, I don't believe extending PGP key actually changes anything but expiration date. While fingerprint of a PGP key includes other fields in the hash, I don't believe expiration date is part of the hash.

  • Thank you. The thing is, is there any RFC or documentation describing it in detail ? I'm asking because imagine the following scenario, if I provide my pub key to someone (it has still an expiry data on it) how can I sync the key ? Should I really have to send again my pub key to him ask him to delete the old one ? – cyzczy Oct 31 '16 at 13:55
  • You could try publishing your updated key to keyservers, and if other party uses (I personally don't) it they will get your new key that way. You could also send them updated key signed with your old one. – Kirill Sinitski Oct 31 '16 at 17:00
  • @Jens Erat. Wow, what a great answer! I have one question. regarding "By extending the validity period, a special self-signature storing the expiry date will be issued. This signature has its own timestamp included, and will override any former expiry dates, so that any other user of OpenPGP will have the new expiry date merged into your old key." So basically we shouldn't "validate" certificates based on their fingerprint in case we are performing key lookups against a key server to check whether the key is expired or nor, is that correct ? – cyzczy Nov 2 '16 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.