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