Making keys unusable with spamming similar uids

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Making keys unusable with spamming similar uids

Valentin Sundermann
Hey sks-devel,

when searching for common terms (i.e. "test") on a keyserver, I hit a
limit of matches sometimes.

Assumed that I'd be a bad person, I should be able to make a choosen key
unusable by creating and uploading keys with similar name, email address
and so on. If somebody searches for that email address, he should hit
the limit and cannot get the key.
(And yeah, it's still possible to get the key with the exact fingerprint
but I guess it's inconvenient for "normal people".)

Do I miss something or is it actually possible to make keys unusable
with such an approach?

If it should be possible: I think something like a pagination should
solve it on a simple level (although the user has to scroll through the
pages and identify the right key). And another thing would be how client
implementation would treat pagination...

Best regards,
Valentin


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Making keys unusable with spamming similar uids

Michael Jones
On 14/09/16 15:27, Valentin Sundermann wrote:

> Hey sks-devel,
>
> when searching for common terms (i.e. "test") on a keyserver, I
> hit a limit of matches sometimes.
>
> Assumed that I'd be a bad person, I should be able to make a
> choosen key unusable by creating and uploading keys with similar
> name, email address and so on. If somebody searches for that email
> address, he should hit the limit and cannot get the key. (And
> yeah, it's still possible to get the key with the exact fingerprint
> but I guess it's inconvenient for "normal people".)
>
> Do I miss something or is it actually possible to make keys
> unusable with such an approach?

as per evil32's demo of 32bit key dupes it's possible to flood these,
but it costs cpu, and even so you can search the keyid-format long value
.

eg;

0x1992274E129BAF74

>
> If it should be possible: I think something like a pagination
> should solve it on a simple level (although the user has to scroll
> through the pages and identify the right key). And another thing
> would be how client implementation would treat pagination...

pagination is an interesting idea, and even more so key ordering which
is currently ordered by key creation date... changing the search
results order would be hard and have politics...

as search results order can't be easily changed, pagination does not
solve the issue (valid keys will be at the bottom of the pile).

the issue being a topic that comes up often enough, what to do with
spam...

Kind Regards,
Mike

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Making keys unusable with spamming similar uids

Valentin Sundermann
> as per evil32's demo of 32bit key dupes it's possible to flood these,
> but it costs cpu, and even so you can search the keyid-format long value
>
> eg;
> 0x1992274E129BAF74
I only thought of same name, email and comment. Searching with the
short/long id and the fingerprint would be still possible.
And yeah, if one wants to make the short id unusable too, it's possible
to generate keys with that id (although it costs more cpu as you already
stated).


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Making keys unusable with spamming similar uids

Brian Minton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

One possibility would be to have the keyserver sort by the time the key
was first seen.  That way, there'd be a slightly lower chance of
getting an impostor's key.   Going by the creation date is not very
useful, since impostors could create their key with whatever creation
date they like. It would still be insecure without fingerprint
verification, but it would perhaps provide a modicum of security.
-----BEGIN PGP SIGNATURE-----

iF4EARYIAAYFAlfcU0MACgkQN7lQes/yAW5deAD7B0tNzA2BH99qVWvpllWCXP+I
Wye6DpjVO+SedSPDwOABAPJoq+x6bepsME8wnvHq5wkaFxJT+hCVkcmzissRoeMK
iF4EAREIAAYFAlfcU0QACgkQa46zoGXPuqlsWQD7BiQuUWAqUr7/ueLjwTKoCTKC
32+/S81Tyl5V7rFp9TYA/1Hjk8kfgVnGdVBwf6RROsOm7Ai4nE+f7xZx+4TcFAqt
=SQiM
-----END PGP SIGNATURE-----

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Making keys unusable with spamming similar uids

Daniel Kahn Gillmor-7
On Fri 2016-09-16 16:17:41 -0400, Brian Minton wrote:

> One possibility would be to have the keyserver sort by the time the
> key was first seen.  That way, there'd be a slightly lower chance of
> getting an impostor's key.  Going by the creation date is not very
> useful, since impostors could create their key with whatever creation
> date they like. It would still be insecure without fingerprint
> verification, but it would perhaps provide a modicum of security.

This goes back to asking the keyservers to operate as trusted parties,
though, which is not something we've traditionally asked of keyserver
operators.

It is also unclear what this means for a new keyserver.  When i set up a
new keyserver, it sees all existing keys at the same time.  and when new
keys are introduced, they propagate through the network in different
orders.  Should the ordering i get back differ from keyserver to
keyserver?

        --dkg

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (947 bytes) Download Attachment