Garbled data in keyservers

Stefan Claas stefan.claas at posteo.de
Thu Dec 6 10:24:59 CET 2018


On Thu, 06 Dec 2018 09:03:32 +0100, Werner Koch wrote:
> On Wed,  5 Dec 2018 19:56, stefan.claas at posteo.de said:
> 
> > 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  
> 
> Right, the fingerprint.  And maybe the long keyid for a transitional
> period because not all software already includes the fingerprint in
> the signature.

O.k.

> > 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.  
> 
> Being able to search for a fingerprint does not allow you to search
> for the latest blockbuster movie to get a torrent link.  Thus there
> is no incentive to use the keyservers as an index and running a
> keyserver will be safer for most operators.

Well, i am not familiar how the current warez etc. scene works,
but my assumption was the following (o.k. i am no programmer...):

As long as we have the option to add additional UID's  to a key my
thinking was, after reading the links from Yegor, that one appends
arbitrary data to a key and provides a link, at some other place, to
that key, in the form of URL://keyserver/keyid_or_fp.

People then would only need a little program to dearmor and
extract the data from that key UID's.

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/20181206/28375bf8/attachment.sig>


More information about the Gnupg-users mailing list