Title gpg --recv-keys/--refresh-keys ignores a given long id, uses short ID instead
Priority wish Status resolved
Category gnupg Due Date
Version all ExtLink  (go)
Superseder Nosy List dkg, dshaw, kro
Assigned To dshaw Topics  (help)

Created on 2011-04-28.10:26:34 by kro, last changed 2011-12-28.22:22:06 by dshaw.

File name Uploaded Type Edit Remove
1340.diff dkg, 2011-08-04.19:18:11 text/x-diff
msg4216 (view) Author: dshaw Date: 2011-12-28.22:18:43
(Understood there are no immediate plans for a release, but if/when we do have 
one, the change will be ready)
msg4215 (view) Author: dshaw Date: 2011-12-28.22:17:24
Change committed to 1.4, 2.0, and master.
msg4156 (view) Author: werner Date: 2011-09-27.15:48:52
We don't have any plans for a new release.
msg4152 (view) Author: dkg Date: 2011-09-23.04:02:01
Can i get an update on where this patch stands?  I'm concerned that people are
actively sniffing around the idea of crafting duplicate short keyids:

They are trivial to create, alas.  The search space is so small, i can exhaust
it in a couple of hours on a crappy 3-year-old netbook.

It would be really great to have gpg avoid using the short keyid wherever
possible, particularly when dealing with data from sketchy sources like the network.
msg4142 (view) Author: paulproteus Date: 2011-08-24.05:03:55
I tested this patch, and it does in fact change the behavior as requested.

Thanks to dkg for writing the patch.

werner, in my limited role as a random enthusiast in the community, I think this
patch in GnuPG. Let me know if there's anything else I can do to help that happen.
msg4132 (view) Author: dshaw Date: 2011-08-11.03:37:03
I think this is fine.  I originally wrote the code to send short keyids as pksd
couldn't properly handle long keyids or fingerprints.  As pksd is now dead, and
sks properly handles this, I think it is reasonable to send the longest ID
appropriate (send fingerprints if we have them, long keyids if we have them, and
short keyids if we must).
msg4130 (view) Author: werner Date: 2011-08-05.15:05:20
David, what do you think about sending long keyids to the keyservers?
msg4129 (view) Author: dkg Date: 2011-08-04.19:18:11
Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.
msg4128 (view) Author: dkg Date: 2011-08-04.19:05:29
Given that the referenced draft was written in 2003, we now have 8 years of
documented expectations that keyservers can do this.  The dominant keyserver
implementation today (SKS) can handle this with no trouble.

All the responsive keyservers in,, and are capable of using longer keyIDs.

Perhaps gpg can now drop the truncation?  It's trivial to craft a key matching a
specific short Key ID.  The fewer places gpg implicitly suggests uniqueness, the
msg4127 (view) Author: werner Date: 2011-08-04.14:40:25
It may be that these days keyservers can cope with long keyids.  However old
keyservers are not able to do that.
msg4126 (view) Author: dkg Date: 2011-08-04.14:25:42
this is not a limitation of the keyservers; gpg itself is stripping all but the
short keyid.  adding "--keyserver-options debug"  to the command shows that in
every case, gpg is requesting the following URL:


However, direct queries of the keyservers show that longer-form keyIDs or full
fingerprints are capable of limiting the number of keys returned.

0 dkg@pip:$ wget -q  -O-
'' | gpg
--list-packets | grep -c '^:public key packet:'
0 dkg@pip:$ wget -q  -O-
'' |
gpg --list-packets | grep -c '^:public key packet:'
0 dkg@pip:$ wget -q  -O-
| gpg --list-packets | grep -c '^:public key packet:'
0 dkg@pip:$ 

Indeed, the hkp I-D suggests [0]:

   Key ID
   strings may be 8 digits (32-bit key ID), 16 digits (64-bit key ID),
   32 digits (version 3 fingerprint), or 40 digits (version 4


I believe the problem is around line 276 of keyserver/gpgkeys_hkp.c, which is
where the truncation happens.
msg4027 (view) Author: werner Date: 2011-04-28.18:57:58
That is a limitation of the keyservers.
msg4026 (view) Author: kro Date: 2011-04-28.10:26:34
When I specifically give a long key ID I want exactly this key, not another one
that would have matched if I hadn't given the long id...

$ gpg --keyserver --recv-keys 7028E350
gpg: requesting key 7028E350 from hkp server
gpg: key 7028E350: public key "Can[censored]" imported
gpg: key 7028E350: public key "Den[censored]" imported

=> OK, there are 2 keys with the same short id, let's delete them both and try
again with the long ID:

$ gpg --keyserver --recv-keys 72236E167028E350                          
gpg: requesting key 7028E350 from hkp server
gpg: key 7028E350: public key "Can[censored]" imported
gpg: key 7028E350: public key "Den[censored]" imported

=> wtf? Ok, let's try with the whole fingerprint as ID:

$ gpg --keyserver --recv-keys 0x137D009EB55B362E7D1A89BB72236E167028E350
gpg: requesting key 7028E350 from hkp server
gpg: key 7028E350: public key "Can[censored]" imported
gpg: key 7028E350: public key "Den[censored]" imported

Please use the long key Id when given, or give a warning message if and why it's
truncated. (is it maybe a keyserver limitation?)
Date User Action Args
2011-12-28 22:22:06dshawsetstatus: chatting -> resolved
2011-12-28 22:18:43dshawsetstatus: resolved -> chatting
messages: + msg4216
2011-12-28 22:17:24dshawsetstatus: in-progress -> resolved
messages: + msg4215
2011-09-27 15:48:52wernersetmessages: + msg4156
2011-09-23 04:02:01dkgsetmessages: + msg4152
2011-08-24 05:03:55paulproteussetmessages: + msg4142
2011-08-11 15:04:32wernersetstatus: chatting -> in-progress
2011-08-11 03:37:03dshawsetmessages: + msg4132
2011-08-05 21:41:57dkgsetnosy: + dkg
2011-08-05 15:05:34wernersetversion: 1.4 -> all
2011-08-05 15:05:20wernersetpriority: bug -> wish
nosy: + dshaw
topic: - nobug
messages: + msg4130
assignedto: dshaw
2011-08-04 19:18:11dkgsetfiles: + 1340.diff
messages: + msg4129
2011-08-04 19:05:29dkgsetmessages: + msg4128
2011-08-04 14:40:25wernersetmessages: + msg4127
2011-08-04 14:25:43dkgsetmessages: + msg4126
2011-04-28 18:57:58wernersettopic: + nobug
status: unread -> chatting
messages: + msg4027
2011-04-28 10:26:34krocreate