Page MenuHome GnuPG

gpg --recv-keys/--refresh-keys ignores a given long id, uses short ID instead
Closed, ResolvedPublic

Description

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 pgp.mit.edu --recv-keys 7028E350
gpg: requesting key 7028E350 from hkp server pgp.mit.edu
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 pgp.mit.edu --recv-keys 72236E167028E350
gpg: requesting key 7028E350 from hkp server pgp.mit.edu
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 pgp.mit.edu --recv-keys 0x137D009EB55B362E7D1A89BB72236E167028E350
gpg: requesting key 7028E350 from hkp server pgp.mit.edu
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?)

Details

Version
all

Related Objects

Event Timeline

kro added projects: gnupg, Bug Report.
kro added a subscriber: kro.
werner added a subscriber: werner.

That is a limitation of the keyservers.

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:

/pks/lookup?op=get&options=mr&search=0x7028E350

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-
'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x7028E350' | gpg
--list-packets | grep -c '^:public key packet:'
2
0 dkg@pip:$ wget -q -O-
'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x72236E167028E350' |
gpg --list-packets | grep -c '^:public key packet:'
1
0 dkg@pip:$ wget -q -O-
'http://pgp.mit.edu:11371/pks/lookup?op=get&options=mr&search=0x137D009EB55B362E7D1A89BB72236E167028E350'

gpg --list-packetsgrep -c '^:public key packet:'

1
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
fingerprint).

[0] https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-3.1.1.1

I believe the problem is around line 276 of keyserver/gpgkeys_hkp.c, which is
where the truncation happens.

It may be that these days keyservers can cope with long keyids. However old
keyservers are not able to do that.

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 keys.gnupg.net, pool.sks-keyservers.net, and
subkeys.pgp.net 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
better.

Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.

David, what do you think about sending long keyids to the keyservers?

werner lowered the priority of this task from Normal to Wishlist.Aug 5 2011, 5:05 PM
werner removed projects: Bug Report, Not A Bug.
werner added a project: Feature Request.
werner changed Version from 1.4 to all.
werner added a subscriber: dshaw.

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).

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.

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:

http://seclists.org/fulldisclosure/2011/Sep/207

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.

We don't have any plans for a new release.

dshaw removed a project: In Progress.

Change committed to 1.4, 2.0, and master.

(Understood there are no immediate plans for a release, but if/when we do have
one, the change will be ready)