This seems like a key from the Evil 32 key set, which rebuilt the OpenPGP web of trust strong set using short key ID collisions to create awareness on how insecure relying on short key IDs is.
Can the public key server system still be trusted?
Sure it can, you just never should (and should have) trusted arbitrary keys on the key server network without building a trust path. Building short key ID collision just brought "fake key attacks" to a new level, but these have always been possible.
What can be done to combat this problem, or reverse the damage?
You cannot really do anything about that key. As all keys from the Evil 32 set have been revoked, at least that key should not be considered at all by others.
But of course, such a key set could be created at any time again! The idea behind the OpenPGP key server network does not provide any trust measures and should not be used for anything but exchanging keys. Trust must be established locally. Always distribute fingerprints or at least long key IDs, and educate your peers about the issue as necessary. Exchange certifications on your real key, for example by joining key signing parties, to enable you and others finding proper trust paths to and from your own key.
However, given that GnuPG and these keys servers rely heavily on short fingerprints, I think this effectively breaks the entire public key server system.
Neither of those rely on short key IDs at all, unless the user makes it to do so. GnuPG has a debatable default of printing short key IDs in overviews, though (which can be changed by using the
keyid-format option (from
Select how to display key IDs. "none" does not show the key ID at all but
shows the fingerprint in a separate line. "short" is the traditional 8-char‐
acter key ID. "long" is the more accurate (but less convenient) 16-character
key ID. Add an "0x" to either to include an "0x" at the beginning of the key
ID, as in 0x99242560. Note that this option is ignored if the option --with-
colons is used.