Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I'm new to pgp & trying to understand how it works.
nginx's signing key is listed here : https://nginx.org/keys/nginx_signing.key
It's fingerprint is : 573B FD6B 3D8F BC64 1079 A6AB ABF5 BD82 7BD9 BF62
If I search for nginx's key on pgp.mit.edu, I get a different looking ascii key whose fingerprint is the same as above.
Why are the "public key block" parts different although the keys are same ?
The fingerprint of a key is calculated over the parts of it that are relevant to ensure you have the right public key.
But a PGP public key can contain more information than that; for example, it can contain a portrait image, it can contain signatures of people who trust your key, their e-mail addresses and so on. The order of these elements may change without changing the fingerprint, and whether or not a key contains an image does nothing to change the fingerprint, because the portrait or the order in which these elements are stored isn't relevant for authenticating the key.
So it's probable that the keyserver changes some of the non-relevant parts of the key; so you get another key block, but the same fingerprint.
Imagine someone messed with Bob's key on the keyserver to change the portrait picture contained in it. The fingerprint would stay the same because even with the wrong portrait, if Alice used the key to encrypt a message to Bob, it could still only be decrypted by Bob's private key.
However, if Malory left Bob's portrait alone but replaced the modulus and exponent of the public key with his own, this would change the fingerprint, and rightly so: It would no longer be Bob's key, and encrypting something with it would give Malory access to it via Malory's private key.
We could build the fingerprint over all the elements of a public key, e.g. including all the signatures and additional personal information about the key owner, but if it worked like that, then every time you updated some trivial information in your key, or someone added another signature to it, your key fingerprint would change, and you'd have to explain to everyone that no, your key wasn't hacked, you just put in an new portrait image where your smile was more radiant.
A GPG key block is not a single key value but consists of multiple packets of different types, following the OpenPGP message format.
In your case, both blocks contain the same public key and user ID packet but the second key lists some additional signature packets.
You can use gpg(1) with --list-packets to enumerate them as follows:
$ gpg --list-packets nginx_signing.key
# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
version 4, algo 1, created 1313747554, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
keyid: ABF5BD827BD9BF62
# off=272 ctb=b4 tag=13 hlen=2 plen=41
:user ID packet: "nginx signing key "
# off=315 ctb=89 tag=2 hlen=3 plen=318
:signature packet: algo 1, keyid ABF5BD827BD9BF62
version 4, created 1466086904, md5len 0, sigclass 0x13
digest algo 2, begin of digest 5a 1a
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 2 len 4 (sig created 2016-06-16)
hashed subpkt 9 len 4 (key expires after 12y303d4h27m)
subpkt 16 len 8 (issuer key ID ABF5BD827BD9BF62)
data: [2047 bits]
# off=636 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid A64FD5B17ADB39A8
version 4, created 1313752997, md5len 0, sigclass 0x10
digest algo 2, begin of digest ef da
hashed subpkt 2 len 4 (sig created 2011-08-19)
subpkt 16 len 8 (issuer key ID A64FD5B17ADB39A8)
data: [2047 bits]
# off=923 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid ECF0E90B2C172083
version 4, created 1313758162, md5len 0, sigclass 0x10
digest algo 2, begin of digest 51 be
hashed subpkt 2 len 4 (sig created 2011-08-19)
subpkt 16 len 8 (issuer key ID ECF0E90B2C172083)
data: [160 bits]
data: [158 bits]
# off=995 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid A9376139A524C53E
version 4, created 1313759073, md5len 0, sigclass 0x10
digest algo 2, begin of digest 73 56
hashed subpkt 2 len 4 (sig created 2011-08-19)
subpkt 16 len 8 (issuer key ID A9376139A524C53E)
data: [159 bits]
data: [156 bits]
Now again with the key from pgp.mit.edu:
$ gpg --list-packets nginx_signing2.key
# off=0 ctb=99 tag=6 hlen=3 plen=269
:public key packet:
version 4, algo 1, created 1313747554, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
keyid: ABF5BD827BD9BF62
# off=272 ctb=b4 tag=13 hlen=2 plen=41
:user ID packet: "nginx signing key "
# off=315 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid ECF0E90B2C172083
version 4, created 1313758162, md5len 0, sigclass 0x10
digest algo 2, begin of digest 51 be
hashed subpkt 2 len 4 (sig created 2011-08-19)
subpkt 16 len 8 (issuer key ID ECF0E90B2C172083)
data: [160 bits]
data: [158 bits]
# off=387 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid A9376139A524C53E
version 4, created 1313759073, md5len 0, sigclass 0x10
digest algo 2, begin of digest 73 56
hashed subpkt 2 len 4 (sig created 2011-08-19)
subpkt 16 len 8 (issuer key ID A9376139A524C53E)
data: [159 bits]
data: [156 bits]
# off=459 ctb=88 tag=2 hlen=2 plen=70
:signature packet: algo 17, keyid E3F93C24A0AF822A
version 4, created 1393414117, md5len 0, sigclass 0x10
digest algo 10, begin of digest b2 d5
hashed subpkt 2 len 4 (sig created 2014-02-26)
subpkt 16 len 8 (issuer key ID E3F93C24A0AF822A)
data: [159 bits]
data: [160 bits]
# off=531 ctb=88 tag=2 hlen=2 plen=94
:signature packet: algo 17, keyid 6B76D872E5287DB2
version 4, created 1453519845, md5len 0, sigclass 0x10
digest algo 8, begin of digest ff c0
hashed subpkt 2 len 4 (sig created 2016-01-23)
subpkt 16 len 8 (issuer key ID 6B76D872E5287DB2)
data: [254 bits]
data: [255 bits]
# off=627 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid A64FD5B17ADB39A8
version 4, created 1313752997, md5len 0, sigclass 0x10
digest algo 2, begin of digest ef da
hashed subpkt 2 len 4 (sig created 2011-08-19)
subpkt 16 len 8 (issuer key ID A64FD5B17ADB39A8)
data: [2047 bits]
# off=914 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid 676B7CC30978D14B
version 4, created 1387022054, md5len 0, sigclass 0x10
digest algo 2, begin of digest 58 70
hashed subpkt 2 len 4 (sig created 2013-12-14)
subpkt 16 len 8 (issuer key ID 676B7CC30978D14B)
data: [2046 bits]
# off=1201 ctb=89 tag=2 hlen=3 plen=284
:signature packet: algo 1, keyid 63563037DB85C154
version 4, created 1477007959, md5len 0, sigclass 0x10
digest algo 10, begin of digest cf 83
hashed subpkt 2 len 4 (sig created 2016-10-20)
subpkt 16 len 8 (issuer key ID 63563037DB85C154)
data: [2047 bits]
# off=1488 ctb=89 tag=2 hlen=3 plen=318
:signature packet: algo 1, keyid ABF5BD827BD9BF62
version 4, created 1466086904, md5len 0, sigclass 0x13
digest algo 2, begin of digest 5a 1a
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 2 len 4 (sig created 2016-06-16)
hashed subpkt 9 len 4 (key expires after 12y303d4h27m)
subpkt 16 len 8 (issuer key ID ABF5BD827BD9BF62)
data: [2047 bits]
# off=1809 ctb=89 tag=2 hlen=3 plen=318
:signature packet: algo 1, keyid ABF5BD827BD9BF62
version 4, created 1313747554, md5len 0, sigclass 0x13
digest algo 2, begin of digest 9b e3
hashed subpkt 2 len 4 (sig created 2011-08-19)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 9 len 4 (key expires after 5y0d0h0m)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
subpkt 16 len 8 (issuer key ID ABF5BD827BD9BF62)
data: [2047 bits]
# off=2130 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid EB17F674C79A40A2
version 4, created 1453812587, md5len 0, sigclass 0x10
digest algo 2, begin of digest d6 ea
hashed subpkt 2 len 4 (sig created 2016-01-26)
subpkt 16 len 8 (issuer key ID EB17F674C79A40A2)
data: [4096 bits]
# off=2673 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 6D688C7C498BF352
version 4, created 1474279425, md5len 0, sigclass 0x10
digest algo 8, begin of digest b5 32
hashed subpkt 2 len 4 (sig created 2016-09-19)
subpkt 16 len 8 (issuer key ID 6D688C7C498BF352)
data: [4096 bits]
# off=3216 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 6D688C7C498BF352
version 4, created 1474423494, md5len 0, sigclass 0x10
digest algo 8, begin of digest f1 d9
hashed subpkt 2 len 4 (sig created 2016-09-21)
subpkt 16 len 8 (issuer key ID 6D688C7C498BF352)
data: [4096 bits]
# off=3759 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 1465F6CF06C1F0CD
version 4, created 1471971424, md5len 0, sigclass 0x10
digest algo 10, begin of digest d7 b0
hashed subpkt 2 len 4 (sig created 2016-08-23)
subpkt 16 len 8 (issuer key ID 1465F6CF06C1F0CD)
data: [4095 bits]
# off=4302 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid A22AE4EB4329C545
version 4, created 1381544106, md5len 0, sigclass 0x12
digest algo 2, begin of digest 0a 50
hashed subpkt 2 len 4 (sig created 2013-10-12)
subpkt 16 len 8 (issuer key ID A22AE4EB4329C545)
data: [4096 bits]
As you can see, the public key packets of both blocks have the same key id (ABF5BD827BD9BF62). The difference in size is caused by the different signature packets while the public key itself is identical.
--list-packets option is good to know, thanks !
The fingerprint is of the actual public key parameters (that is, the RSA modulus and stuff like that). The key blob contains quite a lot more data than that, though; it has the user's identity (name, email, etc.) which can be changed on a key, and (the more common reason for a mismatch) it has other peoples' signatures. The signatures don't impact the parts of the key used for encrypting or verifying signatures, but they do change the contents of the key blob.
If you're curious, the key blobs are basically just base64-encoded certificates (I'm not sure what the actual decoded format is, something binary like ASN1, but you can see ASCII text of things like names and email addresses within it).
