Checking key server response against the request parameters
John at enigmail.net
Fri Sep 20 03:36:29 CEST 2013
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
EXACTLY. Aside from some aggravation and the nuisance value, I cannot see
where this "injection attack" with public or secret keys presents a security
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...
Size: 520 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel