Checking key server response against the request parameters

[John Clizbe]

Nicholas Cole wrote
> 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.

EXACTLY. Aside from some aggravation and the nuisance value, I cannot see
where this "injection attack" with public or secret keys presents a security
risk.

A secret key without the passphrase is just extra bytes in the keyring. Ditto
unasked for public keys. I'll grant the "Where the hell did that come from?"
aggravation but that's the only value I see from this attack.

-- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 520 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130919/d91be338/attachment-0001.sig>