Garbled data in keyservers

[Stefan Claas]

On Wed, 05 Dec 2018 18:53:20 +0100, Werner Koch wrote:
> On Wed,  5 Dec 2018 17:34, stefan.claas at posteo.de said:
> 
> > Can you give more details about the security aspect?  
> 
> People believe that the keyservers magically return a matching key
> for a mail address.  There is no guarantee for this.  In fact all
> people from the strong had meanwhile expired faked key on the
> servers, which was not easy to detect given that they were also
> signed by faked keys from the strong set.
> 
> Thus if you have the capability to sniff mail you would upload a faked
> key and hope that future senders pick up that faked key and encrypt to
> it.  You can now intercept that mail, read it, encrypt to the real key
> and send on.  Even if you can't mount such an active MitM you can
> simply send on the newly encrypted mail with an additional line
> "sorry, I encrypted to the wrong key".
> 
> Right the Web of Trust would stop this attack, but most people are not
> part of the WoT.  Simple methods for initial /key discovery/ are
> required.  Even autocrypt is better than keyservers and with the Web
> Key Directory you can get an even better assurance that it is the
> correct key.

Agreed.

> > run their own key server and analyze the data. So what purpose
> > should your suggestion serve?  
> 
> The additional benefit is that this would take away the load from the
> servers and allow that we can get back the large mesh of keyservers.
> Without being able to search user-ids it does not anymore make sense
> to use keyservers as search engines for magnet links to Bittorrent
> distributed data.

Well, my understanding would be that a least one (search) criteria
would be needed to fetch a key, right? And if so i could also imagine
that this one criteria could be abused as well, in form of a given
link to that resource, as long as it can be fetched via the web.

Regards
Stefan

-- 
https://www.behance.net/futagoza
https://keybase.io/stefan_claas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20181205/bea1e719/attachment.sig>