Checking key server response against the request parameters

Stefan Tomanek tomanek at
Wed Sep 18 19:49:35 CEST 2013

Dies schrieb Nicholas Cole (nicholas.cole at

> I've been following the other patches - but I don't quite follow this
> last scenario at all.  The whole point of keyservers is that they
> don't have to be trusted. Malicious users can (and have) upload fake
> keys all the time.  As long as users check fingerprints and assign
> introducer trust with care, there is no problem.  If I search for John
> H. Newuser's key and get back 1 real and 2 fake ones, the only harm
> that is done is if I fail to check the fingerprints before signing the
> correct one, and my HD has a couple of extra keys on it that I
> probably ought to delete, but which will do no harm, unless I adopt
> the "always trust" trust model and then fail to do any external
> checking.

I just did the actual check and have to agree that the scenario did not work
as expected, since enigmail does not accept keys with unknown trust by default.

But as you said, trusting the key server is not an option, so I still think
that checking their responses against the issued requests is a good thing. I
certainly don't want anyone injecting their spoofed keys into the pubring und
secring of my home directory. While it might not be an immediate threat due to
the seperate trustdb, it is annoying at least. But perhaps that would be a nice
way to distribute my key at conferences, just MitM every keyserver request and
insert my public key material :-)

if(is) - Institut für Internet-Sicherheit
Westfälische Hochschule, Gelsenkirchen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: </pipermail/attachments/20130918/33a8c459/attachment.sig>

More information about the Gnupg-devel mailing list